ISO 17987-2:2016
(Main)Road vehicles — Local Interconnect Network (LIN) — Part 2: Transport protocol and network layer services
Road vehicles — Local Interconnect Network (LIN) — Part 2: Transport protocol and network layer services
ISO 17987-2:2016 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. ISO 17987-2:2016 provides the transport protocol and network layer services to support different application layer implementations like - 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 the ISO 15765‑2 and the PDUs carrying the messages are very similar. The goals of the transport layer are - low load on LIN master node, - to provide full (or a subset thereof) diagnostics directly on the LIN slave nodes, and - targeting clusters built with powerful LIN nodes (not the mainstream low cost).
Véhicules routiers — Réseau Internet local (LIN) — Partie 2: Protocole de transport et couches de services réseau
General Information
Relations
Standards Content (Sample)
DRAFT INTERNATIONAL STANDARD
ISO/DIS 17987-2.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 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
ICS: 35.240.60; 43.040.15
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-2.2:2015(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2015
ISO/DIS 17987-2.2:2015(E)
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
Contents Page
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 . 3
4 Conventions . 4
5 Network management . 4
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 . 9
6.5 Services provided by network layer to higher layers . 12
7 Transport layer protocol . 14
7.1 Protocol functions . 14
7.2 Single frame transmission. 14
7.3 Multiple frame transmission . 14
7.4 Transport layer protocol data units . 16
7.5 Protocol control information specification . 17
7.6 Network layer timing . 20
8 Data link layer usage . 28
8.1 Data link layer service parameters . 28
8.2 Data link layer interface services . 28
8.3 Mapping of the N_PDU fields . 29
8.4 Transport layer PDU structure and communication . 29
9 Diagnostic communication requirements . 32
9.1 Definition of diagnostic classes . 32
9.2 Diagnostic messages . 33
9.3 Using the transport layer . 33
9.4 Slave node diagnostic timing requirements . 34
9.5 Response Pending . 36
9.6 Transport protocol handling in LIN master . 37
9.7 Transmission handler requirements . 43
9.8 Diagnostic service prioritization . 48
10 LIN node capability language (NCL) . 50
10.1 General . 50
10.2 Plug and play workflow concept . 50
11 Node capability file (NCF) . 52
11.1 Overview of NCF syntax . 52
11.2 Global structure definition. 52
11.3 Node definition . 53
11.4 NCF example . 58
12 LIN description file (LDF) . 59
12.1 General . 59
12.2 Overview of LDF syntax . 59
12.3 LDF definition . 59
ISO/DIS 17987-2.2
12.4 LDF example . 74
iv © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
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-2 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
ISO/DIS 17987-2.2
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 transportation.
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;
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 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.
vi © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
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.
DRAFT INTERNATIONAL STANDARD ISO/DIS 17987-2.2
1 Road vehicles — Local Interconnect Network (LIN) — Part 2:
2 Transport protocol and network layer services
3 1 Scope
4 This part of ISO 17987 specifies a transport protocol and network layer services tailored to meet the
5 requirements of LIN-based vehicle network systems on local interconnect networks. The protocol specifies an
6 unconfirmed communication.
7 The LIN protocol supports the standardized service primitive interface as specified in ISO 14229-2.
8 This part of ISO 17987 provides the transport protocol and network layer services to support different
9 application layer implementations like
10 Normal communication messages;
11 Diagnostic communication messages;
12 The transport layer defines transportation of data that is contained in one or more frames. The transport layer
13 messages are transported by diagnostic frames. A standardized API is specified for the transport layer.
14 Use of the transport layer is targeting systems where diagnostics are performed on the backbone bus (e.g.
15 CAN) and where the system builder wants to use the same diagnostic capabilities on the LIN sub-bus
16 clusters. The messages are in fact identical to the ISO 15765-2 and the PDUs carrying the messages are very
17 similar.
18 The goals of the transport layer are
19 low load on LIN master node;
20 to provide full (or a subset thereof) diagnostics directly on the LIN slave nodes;
21 targeting clusters built with powerful LIN nodes (not the mainstream low cost);
22 A typical system configuration is shown in Figure 1.
back-bone bus
Tester
Master
LIN cluster
Slave 2
Slave 1
24 Figure 1 — Typical system setup for a LIN cluster using the transport layer
ISO/DIS 17987-2.2
25 2 Normative references
26 The following referenced documents are indispensable for the application of this document. For dated
27 references, only the edition cited applies. For undated references, the latest edition of the referenced
28 document (including any amendments) applies.
29 ISO 17987 (Part 2, 4, 6 and 7), Road vehicles – Local Interconnect Network (LIN)
30 3 Terms, definitions, symbols and abbreviated terms
31 3.1 Terms and definitions
32 For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1 apply.
33 3.1.1
34 Broadcast NAD
35 Any slave node receiving a message with a NAD equal to the broadcast NAD 7F the message is received
36 and processed.
37 3.1.2
38 Configured NAD
39 Each of the slave nodes requires a unique configured NAD which is used for node configuration and
40 identification services as well as UDS services according to ISO 14229-7. The assignment of configured NAD
41 is defined in the LDF.
42 The master node can assign new configured NADs to slave nodes supporting the "Assign NAD" service.
43 The configured NAD is in the range [01 – 7D ].
16 16
44 An API alternatively used in a slave node to assign the configured NAD.
45 The configured NAD is assigned with a static configuration
46 3.1.3
47 Functional NAD
48 (7E ) Used to broadcast diagnostic requests
49 3.1.4
50 Initial NAD
51 Each of the slave nodes shall have an initial NAD. The combination of initial NAD, Suppler ID and Function ID
52 shall be unique in a LIN cluster. The initial NAD value is constant/static and may be derived before entering
53 the operational state (regular LIN communication) from a pin configuration, EEPROM or slave node position
54 detection algorithms. The initial NAD is used to assign a unique configured NAD. If no initial NAD is defined
55 for a slave node (LDF, NCF) the value is identical to the configured NAD. The initial NAD is in the range of
56 [01 – 7D ]
16 16
57 3.1.5
58 P2 timing parameter
59 Application timing parameter for the ECU(s) and the external test equipment
60 3.1.6
61 P2* timing parameter
62 Enhanced response timing parameter for the ECU(s) application after response pending frame transmission
63 3.1.7
64 P4 timing parameter
65 Timing parameter for the ECU(s) application defining the time between reception of a request and the final
66 response
2 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
67 3.1.8
68 Proprietary NAD
69 NAD values in the range [80 – FF ] are used for not standardized communication purpose such as Tier-1
16 16
70 slave node diagnostics.
72 3.2 Symbols
% percentage
µ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
74 3.3 Abbreviated terms
API application programmers interface
BNF Bachus-Naur format
CF ConsecutiveFrame
FF FirstFrame
LDF LIN description file
L_Data data link data
MRF master request frame
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
ISO/DIS 17987-2.2
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 slave 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
RSID response service identifier
SF SingleFrame
SID service identifier
SN SequenceNumber
SRF slave response frame
ST SeparationTime minimum
min
75 4 Conventions
76 ISO 17987 (all parts) and ISO 14229-7 [5] are based on the conventions specified in the OSI Service
77 Conventions (ISO/IEC 10731) [2] as they apply for physical layer, protocol, transport protocol & network layer
78 services and diagnostic services.
79 5 Network management
80 5.1.1 Network management general information
81 Network management in a LIN cluster refers to cluster wake up and go-to-sleep only. Other network
82 management features, e.g. configuration detection and limp home management are left to the application.
83 5.1.2 LIN node communication state diagram
84 The state diagram in Figure 2 shows the behaviour model for LIN communication state.
4 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
85 Bus Sleep
86 Bus Sleep state is entered after first connection to power source and the system initialization, reset or
87 when a go-to-sleep command is transmitted by the master or received by the slave node. The level on the
88 bus is set to recessive. Only the wake up signal may be transmitted on the cluster.
89 Operational
90 The protocol behaviour (transmitting and receiving frames) specified in this document only applies to the
91 Operational state.
93 Note: The LIN 'Bus Sleep' state does not necessarily correlate to the node's power state.
Wake up signal received
OR
internal reason to wake up the cluster
Bus Sleep Operational
Go-to-sleep command
transmitted / received OR
bus inactivity for 4 to 10 s
96 Figure 2 — LIN node communication state diagram
98 5.1.3 Wake up
99 5.1.3.1 Wake up general information
100 Any node in a sleeping LIN cluster may request a wake up, by transmitting a wake up signal. The wake up
101 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
102 bus signal to the recessive state.
103 5.1.3.2 Master generated wake up
104 The master node may issue a break field, e.g. by issuing an ordinary header since the break acts as a wake
105 up signal (in this case the master shall be aware of that this frame may not be processed by the slave nodes
106 since they may not yet awake and ready to listen to headers).
107 Every slave node (connected to power) should detect the wake up signal (a dominant pulse longer than
108 150 µs followed by a rising edge of the bus signal) and be ready to listen to bus commands within 100 ms,
109 measured from the ending edge of the dominant pulse, see Figure 3. The check for the rising edge shall be
110 done by the transceiver and also could be done by the microcontroller LIN interface.
111 A detection threshold of 150 µs combined with a 250 µs pulse generation gives a detection margin that is
112 enough for uncalibrated slave nodes. Following the detection of the wake up pulse, the Slave task machine
ISO/DIS 17987-2.2
113 (ISO 17987-3 subclause 7.5.3) shall start and enter into the idle state. During the idle state, the slave shall
114 never issue a dominant level pulse on the bus until the state machine enters into an active state.
115 5.1.3.3 Slave generated wake up
116 If the node that transmitted the wake up signal is a slave node, it shall be ready to receive or transmit frames
117 immediately. The master node shall also wake up and, when the slave nodes are ready (>100 ms), start
118 transmitting headers to find out the cause (using signals) of the wake up.
The slave node is
ready to receive or
Slave node is initializing
transmit frames
> 150 µs max 100 ms
120 Figure 3 — Wake up signal reception in slave nodes
122 The master node shall detect the wake up signal (a dominant pulse longer than 150 µs followed by a rising
123 edge of the bus signal) and be ready to start communication within a time that is decided by the cluster
124 designer or application specific. The check for the rising edge shall be done by the transceiver and also could
125 be done by the microcontroller LIN interface.
126 If the master node does not transmit a break field (i.e. starts to transmit a frame) or if the node issuing the
127 wake up signal does not receive a wakeup signal (from another node) within 150 ms to 250 ms from the wake
128 up signal, the node issuing the wake up signal shall transmit a new wake up signal, see Figure 4. In case the
129 slave node transmits a wake up signal in the same time as the master node transmits a break field, the slave
130 shall receive and recognize this break field.
250µs – 5ms 150 ms – 250 ms 250µs – 5ms 150 ms – 250 ms 250µs – 5ms
132 Figure 4 — One block of wake up signals
134 After three (failing) requests the node shall wait minimum 1,5 s before issuing a fourth wake up signal. The
135 reason for this longer duration is to allow the cluster to communicate in case the waking slave node has
136 problems, e.g. if the slave node has problems with reading the bus it probably retransmit the wake up signal
137 infinitely. There is no restriction of how many times a slave may transmit the wake up signal. However, it is
138 recommended that a slave node transmits not more than one block of three wake up signals for each wake up
139 condition. Figure 5 shows how wake up signals are transmitted over a longer time
6 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
> 1,5 s > 1,5 s > 1,5 s
142 Figure 5 — Wake up signals over long time
144 5.1.4 Go-to-sleep
145 The master sets each node in the cluster instantly into bus sleep state by transmitting a go-to-sleep command.
146 The request does not necessarily enforce the slave nodes into a low-power mode. The slave node application
147 may still be active after the go-to-sleep command has been received. This behaviour is application specific.
148 The go-to-sleep command is a master request frame with the first data field (Byte 1) set to 00 and the rest
149 set to FF , see Table 1. The slave nodes shall ignore the data fields (bytes) 2 to 8 and interpret only the first
150 data field (Byte 1).
151 Table 1 — Go-to-sleep command
LIN frame
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
00 FF FF FF FF FF FF FF
16 16 16 16 16 16 16 16
153 The normal way for setting the cluster to sleep is that the master node transmits the go-to-sleep command. In
154 case of bus inactivity a slave node shall be able to receive/transmit frames for 4 s. The slave node shall
155 automatically enter bus sleep mode earliest 4 s and latest 10 s of bus inactivity. Bus inactivity is defined as no
1)
156 transitions between recessive and dominant bit values . Bus activity is the inverse.
1) LIN transceivers normally have filters to remove short spikes on the bus. The transition here refers to the signal after
this filter.
ISO/DIS 17987-2.2
158 6 Network layer overview
159 6.1 General
160 This part of ISO 17987 specifies an unconfirmed network layer communication protocol for the exchange of
161 data between network nodes, e.g. from ECU to ECU, or between external test equipment and an ECU. If the
162 data to be transferred do not fit into a single LIN frame, a segmentation method is provided.
163 In order to describe the function of the network layer, services provided to higher layers and the internal
164 operation of the network layer shall be considered.
165 All network layer services have the same general structure. To define the services, three types of service
166 primitives are specified:
167 a service request primitive, used by higher communication layers or the application to pass control
168 information and data required to be transmitted to the network layer;
169 a service indication primitive, used by the network layer to pass status information and received data to
170 upper communication layers or the application;
171 a service confirmation primitive, used by the network layer to pass status information to higher
172 communication layers or the application.
173 This service specification does not specify an application programming interface, but only a set of service
174 primitives that are independent of any implementation.
175 6.2 Format description of network layer services
176 All network layer services have the same general format. Service primitives are written in the form:
177 service_name.type (
178 parameter A,
179 parameter B
180 [,parameter C, .]
181 )
182 where "service_name" is the name of the service, e.g. N_USData, "type" indicates the type of the service
183 primitive, and "parameter A, parameter B [parameter C, .]" are the N_SDU as a list of values passed by the
184 service primitive. The brackets indicate that this part of the parameter list may be empty.
185 The service primitives define how a service user (e.g. diagnostic application) cooperates with a service
186 provider (e.g. network layer). The following service primitives are specified in this International Standard:
187 request, indication and confirm.
188 Using the service primitive request (service_name.request), a service user requests a service from
189 the service provider.
190 Using the service primitive indication (service_name.indication), the service provider informs a
191 service user about an internal event of the network layer or the service request of a peer protocol layer
192 entity service user.
193 With the service primitive confirm (service_name.confirm), the service provider informs the service
194 user about the result of a preceding service request of the service user.
8 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
196 6.3 Internal operation of network layer
197 The internal operation of the network layer provides methods for segmentation and reassembly. The main
198 purpose of the network layer is to transfer messages that might or might not fit in a single LIN frame.
199 Messages that do not fit into a single LIN frame are segmented into multiple parts, where each can be
200 transmitted in a LIN frame.
201 Figure 6 and Figure 7 show, respectively, an example of an unsegmented message transmission and of a
202 segmented message transmission.
Sender Receiver
SingleFrame (SF)
204 Figure 6 — Example of an unsegmented message
Sender Receiver
FirstFrame
(FF)
ConsecutiveFrame
(CF)
ConsecutiveFrame
(CF)
:
ConsecutiveFrame
(CF)
207 Figure 7 — Example of a segmented message
209 6.4 Service data unit specification
210 In the following subclauses all network layer service parameters are described which are used by the LIN
211 network layer services.
ISO/DIS 17987-2.2
212 6.4.1 N_AI, Address Information
213 6.4.1.1 N_AI description
214 The N_AI is used to identify the communicating peer entities of the network layer. N_AI consists of a LIN ID
215 and a N_NAD. Two dedicated LIN IDs are used for any transport layer protocol communication.
216 ID 3C (MasterReq) is assigned to the message transmissions sent by the master node.
217 ID 3D (SlaveResp) is assigned to the message transmissions sent by any slave node.
218 Because the node type (Master or Slave) is always fixed for all nodes in a LIN cluster the LIN ID used is no
219 subject of the service primitive parameters of chapter 6.5.1 but assigned to each node by this standard.
220 Additionally a N_NAD comprises the slave node addressed by the request/response and also the addressing
221 type (physical, functional, broadcast).
222 These parameters refer to addressing information. As a whole, the N_AI parameters are used to identify the
223 message senders and recipients as well as the communication model for the message (N_TAtype).
224 6.4.1.2 N_NAD, Network NAD
225 Type: 1 byte unsigned integer value
226 Range: 01 – FF
16 16
227 Description: Two communication models are specified:
228 1 to 1 communication, called physical addressing, and
229 1 to n communication called functional addressing or broadcast addressing.
230 Depending on the N_NAD value the communication model is given:
231 00 : not applicable, reserved for sleep command frame
232 01 – 7D : physical addressing type
16 16
233 7E : functional addressing type
234 7F : broadcast addressing type
235 80 – FF : proprietary addressing type
16 16
236 Physical addressing shall be supported for all types of network layer messages. Responses on requests are
237 expected. The N_NAD value shall always validated against the configured NAD in a slave node.
238 Functional addressing shall only be supported for SingleFrame communication. No responses shall be
239 transmitted on functional requests. The master node is the only node transmitting functional messages.
240 Broadcast addressing shall be supported for all types of network layer messages. Responses are unexpected
241 but supported even if they could raise collisions. The master node shall be the only node transmitting
242 broadcast messages.
243 The addressing type of NAD values in range 80 – FF is unassigned by this standard and shall be assigned
16 16
244 by users when this range of NAD is used.
10 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
245 6.4.2
246 Type: 12 bits
247 Range: 001 - FFF
16 16
248 Description: This parameter includes the length of data to be transmitted / received.
249 6.4.3
250 Type: string of bytes
251 Range: not applicable
252 Description: This parameter includes all data the higher layer entities exchange.
253 6.4.4
254 Type: enumeration
255 Range: N_OK, N_TIMEOUT_As, N_TIMEOUT_Cs, N_TIMEOUT_Cr, N_WRONG_SN, N_UNEXP_PDU,
256 N_ERROR, N_UNEXP_NEW_REQ
257 Description: This parameter contains the status relating to the outcome of a service execution. If two or more
258 errors are discovered at the same time, then the network layer entity shall use the parameter value first found
259 in this list in the error indication to the higher layers.
260 N_OK
261 This value means that the service execution has completed successfully; it can be issued to a service user on
262 both the sender and receiver side.
263 N_TIMEOUT_As
264 This value is issued to the service user on the sender side when the timer N_As has passed its timeout value
265 N_As .
max
266 N_TIMEOUT_Cs
267 This value is issued to the protocol user on the sender side when the timer N_Cs has passed its timeout value
268 N_Cs .
max
269 N_TIMEOUT_Cr
270 This value is issued to the service user on the sender side when the timer N_Cr has passed its timeout value
271 N_Cr .
max
272 N_WRONG_SN
273 This value is issued to the service user upon reception of an unexpected SequenceNumber (N_PCI.SN)
274 value; it can be issued to the service user on the receiver side only.
275 N_UNEXP_PDU
276 This value is issued to the service user upon reception of an unexpected protocol data unit; it can be issued to
277 the service user on the receiver or transmitter side.
278 N_ERROR
ISO/DIS 17987-2.2
279 This is the general error value. It shall be issued to the service user when an error has been detected by the
280 network layer and no other parameter value can be used to better describe the error. It can be issued to the
281 service user on both the sender and receiver side.
282 N_UNEXP_NEW_REQ
283 This value is issued
284 a) to the lower priority service instances with an active diagnostic communication as parameter of
285 N_USData.indication() upon service call of a new higher priority call of N_USData.request.
286 b) when a N_USData.request can’t be accepted due to a currently active diagnostic communication with a
287 higher priority.
288 c) this value is issued to the service user upon service call of a new N_USData.request with the same
289 priority.
290 6.5 Services provided by network layer to higher layers
291 The service interface defines a set of services that are needed to access the functions offered by the network
292 layer, i.e. transmission/reception of data and setting of protocol parameters.
293 The communication services, of which the following are defined, enable the transfer of up to 4095 bytes of
294 data.
295 d) N_USData.request
296 This service is used to request the transfer of data. If necessary, the network layer segments the data.
297 e) N_USData_FF.indication
298 This service is used to signal the beginning of a segmented message reception to the upper layer.
299 f) N_USData.indication
300 This service is used to provide received data to the higher layers.
301 g) N_USData.confirm
302 This service confirms to the higher layers that the requested service has been carried out (successfully or
303 not).
304 6.5.1 Specification of network layer service primitives
305 6.5.2 N_USData.request
306 The service primitive requests transmission of with bytes from the sender to the
307 receiver peer entities identified by the address information in N_NAD (see 6.4.1.2 for parameter definition).
308 Each time the N_USData.request service is called, the network layer shall signal the completion (or failure)
309 of the message transmission to the service user by means of the issuing of a N_USData.confirm service
310 call:
311 N_USData.request (
312 N_NAD
313
314
315 )
12 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
316 6.5.3 N_USData.confirm
317 The N_USData.confirm service is issued by the network layer. The service primitive confirms the
318 completion of a N_USData.request service identified by the address information in N_NAD. The parameter
319 provides the status of the service request (see 6.4.4 for parameter definition).
320 N_USData.confirm (
321 N_NAD
322
323 )
324 6.5.4 N_USData_FF.indication
325 The N_USData_FF.indication service is issued by the network layer. The service primitive indicates to
326 the adjacent upper layer the arrival of a FirstFrame (FF) of a segmented message received from a peer
327 protocol entity, identified by the address information in N_NAD (see 6.4.1.2 for parameter definition). This
328 indication shall take place upon reception of the FirstFrame (FF) of a segmented message.
329 N_USData_FF.indication (
330 N_NAD
331
332 )
333 The N_USData_FF.indication service shall always be followed by an N_USData.indication service
334 call from the network layer, indicating the completion (or failure) of the message reception.
335 A N_USData_FF.indication service call shall only be issued by the network layer if a correct FirstFrame
336 (FF) message segment has been received.
337 If the network layer detects any type of error in a FirstFrame (FF), then the message shall be ignored by the
338 network layer and no N_USData_FF.indication shall be issued to the adjacent upper layer.
339 If the network layer receives a FirstFrame (FF) with a data length value (FF_DL) that is greater than the
340 available receiver buffer size, then this shall be considered as an error condition and no
341 N_USData_FF.indication shall be issued to the adjacent upper layer.
342 6.5.5 N_USData.indication
343 The N_USData.indication service is issued by the network layer. The service primitive indicates
344 events and delivers with bytes received from a peer protocol entity
345 identified by the address information in N_NAD to the adjacent upper layer (see 6.4.1.2 for parameter
346 definition).
347 The parameters and are only valid if equals N_OK.
348 N_USData.indication (
349 N_NAD
350
351
352
353 )
354 The N_USData.indication service call is issued after the reception of a SingleFrame (SF) message or as
355 an indication of the completion (or failure) of a segmented message reception.
356 If the network layer detects any type of error in a SingleFrame (SF), then the message shall be ignored by the
357 network layer and no N_USData.indication shall be issued to the adjacent upper layer.
ISO/DIS 17987-2.2
358 7 Transport layer protocol
359 7.1 Protocol functions
360 The transport layer protocol performs the following functions:
361 transmission / reception of messages up to 4095 data bytes;
362 reporting of transmission / reception completion / failure occurrence.
363 7.2 Single frame transmission
364 Figure 8 shows the transmission of a SingleFrame (SF) called LIN frame, which consists of 8 bytes (Byte 1 …
365 Byte 8) with Byte 1 = N_ NAD, Byte 2 = N_PCI and Byte 3 … Byte 8 = N_Data. The actual message payload
366 of a SF (see 7.4.2) is up to 6 data bytes. See also 8.3).
Higher Layer of Higher Layer of
the Sender the Receiver
N_SDU with less or N_SDU with less or
equal than 6 data equal than 6 data
bytes bytes
Transmission
to peer entity
SF N_PDU SF N_PDU
Network Layer of Network Layer of
the Sender the Receiver
369 Figure 8 — Example of a SingleFrame (SF) transmission
371 7.3 Multiple frame transmission
372 Transmission of longer messages is performed via segmentation of the message into LIN frames
373 (transmission of multiple N_PDUs). Reception of longer messages is performed via reception of multiple LIN
374 frames (N_PDUs) and reassembly of the received data bytes (concatenation) into a message. The multiple
375 N_PDUs are called FirstFrame (for the first N_PDU of the message) and ConsecutiveFrame (for all the
376 following N_PDUs).
377 Messages longer than the allowed number of data bytes contained in a SF N_PDU are segmented into:
378 a FirstFrame protocol data unit (FF N_PDU), containing Byte 1 = N_ NAD, Byte 2 + Byte 3 = N_PCI and
379 Byte 4 . Byte 8 = N_Data. The actual payload of a FF (see 7.4.3 and 8.3) is 5 data bytes, and
380 one or more ConsecutiveFrame protocol data units (CF N_PDU), containing Byte 1 = N_NAD, Byte 2 =
381 N_PCI and Byte 3 . Byte 8 = N_Data. The actual payload of a CF (see 7.4.4 and 8.3) is 6 data bytes. The
382 last CF N_PDU contains the remaining valid payload data bytes N_Data. Unused data bytes in the last
383 CF N_PDU are stuffed with value FF .
14 © ISO 2015 – All rights reserved
ISO/DIS 17987-2.2
384 Figure 9 shows segmentation at the sender side and reassembly at the receiver side.
Higher Layer of Higher Layer of
the Sender the Receiver
N_SDU with more N_SDU with more
than 6 than 6
...
INTERNATIONAL ISO
STANDARD 17987-2
First edition
2016-08-15
Road vehicles — Local Interconnect
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 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 .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 . 4
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 Master generated wake up . 6
5.3.3 Slave generated wake up . 6
5.4 Go-to-sleep . 8
6 Network layer overview . 8
6.1 General . 8
6.2 Format description of network layer services . 9
6.3 Internal operation of network layer . 9
6.4 Service data unit specification .10
6.4.1 N_AI, address information .10
6.4.2 .11
6.4.3 .11
6.4.4 .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 .13
7 Transport layer protocol .14
7.1 Protocol functions .14
7.2 Single frame transmission .14
7.3 Multiple frame transmission .14
7.4 Transport layer protocol data units .16
7.4.1 Protocol data unit types . .16
7.4.2 SF N_PDU .16
7.4.3 FF N_PDU .16
7.4.4 CF N_PDU .16
7.4.5 Protocol data unit field description .16
7.5 Protocol control information specification .17
7.5.1 N_PCI .17
7.5.2 SingleFrame N_PCI parameter definition .18
7.5.3 FirstFrame N_PCI parameter definition .19
7.5.4 ConsecutiveFrame N_PCI parameter definition .19
7.6 Network layer timing .20
7.6.1 Timing constraints .20
7.6.2 Network layer timeouts .25
7.6.3 Network layer error handling .25
7.6.4 Unexpected arrival of N_PDU .26
8 Data link layer usage .27
8.1 Data link layer service parameters .28
8.2 Data link layer interface services .28
8.2.1 L_Data.request .28
8.2.2 L_Data.confirm .28
8.2.3 L_Data.indication .28
8.3 Mapping of the N_PDU fields .28
8.4 Transport layer PDU structure and communication .29
8.4.1 PDU structure .29
8.4.2 Communication .31
9 Diagnostic communication requirements .31
9.1 Definition of diagnostic classes .31
9.1.1 General.31
9.1.2 Diagnostic class I . . .31
9.1.3 Diagnostic class II .31
9.1.4 Diagnostic class III .31
9.1.5 Summary of slave node diagnostic classes .32
9.2 Diagnostic messages .32
9.3 Using the transport layer .32
9.4 Slave node diagnostic timing requirements .34
9.5 Response pending .36
9.6 Transport protocol handling in LIN master .36
9.6.1 General.36
9.6.2 Diagnostic master request schedule .36
9.6.3 Diagnostic slave response schedule .37
9.6.4 Diagnostic schedule execution .37
9.7 Transmission handler requirements .42
9.7.1 General.42
9.7.2 Master node transmission handler .42
9.7.3 Slave 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 Overview of NCF syntax .51
11.2 Global structure definition .51
11.2.1 Node capability file marker .51
11.2.2 Language version number definition .52
11.2.3 NCF revision .52
11.2.4 Big-endian signal encoding variant .52
11.3 Node definition .52
11.3.1 General node definition .52
11.3.2 Diagnostic definition .53
11.3.3 Frame definition .54
11.3.4 Signal encoding type definition.55
11.3.5 Status management .56
11.3.6 Free text definition .56
11.4 NCF example .56
12 LIN description file (LDF) .57
12.1 General .57
12.2 Overview of LDF syntax .57
iv © ISO 2016 – All rights reserved
12.3 LDF definition .58
12.3.1 Global structure definition .58
12.3.2 Signal definition .59
12.3.3 Frame definition .60
12.3.4 Node definition .62
12.3.5 Schedule table definition .65
12.3.6 Signal encoding type definition.67
12.3.7 Signal representation definition .69
12.4 LDF example .69
Bibliography .72
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, SC 31, Data communication.
A list of all parts in the ISO 17987 series can be found on the ISO website.
vi © ISO 2016 – All rights reserved
Introduction
This 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 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, master/slave communication with error
detection, node configuration and diagnostic service transportation.
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;
— 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 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 the following.
— ISO 17987-1: This part provides an overview of the 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.
— 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 application programmers interface (API) 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.
viii © ISO 2016 – All rights reserved
INTERNATIONAL STANDARD ISO 17987-2:2016(E)
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 like
— 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 the ISO 15765-2 and the PDUs carrying the messages
are very similar.
The goals of the transport layer are
— low load on LIN master node,
— to provide full (or a subset thereof) diagnostics directly on the LIN slave nodes, and
— targeting 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 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements
ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
ISO 14229-7:2015, Road vehicles — Unified diagnostic services (UDS) — Part 7: UDS on local interconnect
network (UDSonLIN)
ISO 17987-3:2016, 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/IEC 7498-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
broadcast NAD
slave node receiving a message with a NAD equal to the broadcast NAD 7F the message is received
and processed
2 © ISO 2016 – All rights reserved
3.1.2
configured NAD
value in the range of (01 to 7D ) which is assigned to each slave node
16 16
Note 1 to entry: The assignment of configured NAD to each slave 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 slave nodes may be identical. The master
shall assign unique configured NADs to all slave nodes before diagnostic communication begins.
Note 3 to entry: Setting or altering the configured NAD in a slave node can be done by the following ways:
— the master node assigns a new configured NAD to a slave node supporting the “Assign NAD” service;
— an API call in a slave node assigns the configured NAD;
— the configured NAD is assigned with a static configuration.
3.1.3
functional NAD
(7E )
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 slave 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 slave node is used in
the “Assign NAD” command allowing an unambiguous configured NAD assignment.
Note 3 to entry: If no initial NAD is defined for a slave 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.1.8
proprietary NAD
NAD values in the range [80 – FF ] are used for not standardized communication purpose, such as
16 16
Tier-1 slave node diagnostics
3.2 Symbols
% percentage
µ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 programmers interface
BNF Bachus-Naur format
CAN Controller Area Network
CF ConsecutiveFrame
FF FirstFrame
LDF LIN description file
L_Data data link data
MRF master request frame
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 slave nodes
4 © ISO 2016 – All rights reserved
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
RSID response service identifier
SF SingleFrame
SID service identifier
SN SequenceNumber
SRF slave response frame
ST SeparationTime minimum
min
4 Conventions
ISO 17987 (all parts) 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 first connection to power source and the system initialization, reset
or when a go-to-sleep command is transmitted by the master or received by the slave 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 LIN “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 Master generated wake up
The master 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 master shall be aware of that this frame may not be processed by the
slave nodes since they may not yet awake and ready to listen to headers).
Every slave 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 also could 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 slave nodes. Following the detection of the wake up pulse, the Slave task
machine (ISO 17987-3:2016, 7.5.3) shall start and enter into the idle state. During the idle state, the slave
shall never issue a dominant level pulse on the bus until the state machine enters into an active state.
5.3.3 Slave generated wake up
If the node that transmitted the wake up signal is a slave node, it shall be ready to receive or transmit
frames immediately. The master node shall also wake up and, when the slave nodes are ready (>100 ms),
start transmitting headers to find out the cause (using signals) of the wake up.
6 © ISO 2016 – All rights reserved
Figure 3 — Wake up signal reception in slave nodes
The master 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 application specific. The check for the rising edge shall be done by the transceiver
and also could be done by the microcontroller LIN interface.
If the master 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 wakeup signal (from another node) within 150 ms to 250 ms
from the wake up signal, the node issuing the wake up signal shall transmit a new wake up signal
(see Figure 4). In case the slave node transmits a wake up signal in the same time as the master node
transmits a break field, the slave shall receive and recognize this break field.
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 slave node
has problems, e.g. if the slave node has problems with reading the bus it probably retransmit the wake
up signal infinitely. There is no restriction of how many times a slave may transmit the wake up signal.
However, it is recommended that a slave node transmits not more than one block of three wake up signals
for each wake up condition. Figure 5 shows how wake up signals are transmitted over a longer time
Figure 5 — Wake up signals over long time
5.4 Go-to-sleep
The master sets each node in the cluster instantly into bus sleep state by transmitting a go-to-sleep
command. The request does not necessarily enforce the slave nodes into a low-power mode. The slave
node application may still be active after the go-to-sleep command has been received. This behaviour
is application specific. The go-to-sleep command is a master request frame with the first data field
(Byte 1) set to 00 and the rest set to FF (see Table 1). The slave nodes shall ignore the data fields
16 16
Byte 2 to Byte 8 and interpret only the first data field (Byte 1).
Table 1 — Go-to-sleep command
LIN frame
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
00 FF FF FF FF FF FF FF
16 16 16 16 16 16 16 16
The normal way for setting the cluster to sleep is that the master node transmits the go-to-sleep
command. In case of bus inactivity, a slave node shall be able to receive/transmit frames for 4 s. The
slave node shall automatically enter bus sleep mode earliest 4 s and latest 10 s of bus inactivity. Bus
inactivity is defined as no transitions between recessive and dominant bit values. Bus activity is the
inverse.
NOTE LIN transceivers normally have filters to remove short spikes on the bus. The transition here refers to
the signal after this filter.
6 Network layer overview
6.1 General
This document specifies an unconfirmed network layer communication protocol for the exchange of
data between network nodes, e.g. from ECU to ECU, or between external test equipment and an ECU. If
the data to be transferred do not fit into a single LIN frame, a segmentation method is provided.
In order to describe the function of the network layer, services provided to higher layers and the
internal operation of the network layer shall be considered.
All network layer services have the same general structure. To define the services, three types of
service primitives are specified:
— a service request primitive, used by higher communication layers or the application to pass control
information and data required to be transmitted to the network layer;
— a service indication primitive, used by the network layer to pass status information and received
data to upper communication layers or the application;
— a service confirmation primitive, used by the network layer to pass status information to higher
communication layers or the application.
This service specification does not specify an application programming interface, but only a set of
service primitives that are independent of any implementation.
8 © ISO 2016 – All rights reserved
6.2 Format description of network layer services
All network layer services have the same general format. Service primitives are written in the form:
service_name.type (
parameter A,
parameter B
[,parameter C, .]
)
where service_name is the name of the service, e.g. N_USData, type indicates the type of the service
primitive, and “parameter A, parameter B [parameter C, .]” are the N_SDU as a list of values passed by
the service primitive. The brackets indicate that this part of the parameter list may be empty.
The service primitives define how a service user (e.g. diagnostic application) cooperates with a service
provider (e.g. network layer). The following service primitives are specified in this document: request,
indication and confirm.
— Using the service primitive request (service_name.request), a service user requests a service
from the service provider.
— Using the service primitive indication (service_name.indication), the service provider
informs a service user about an internal event of the network layer
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...