0% found this document useful (0 votes)

1K views156 pages

Pas 62405

PAS 62405

Uploaded by

Nalex Gee

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

1K views156 pages

Pas 62405

PAS 62405

Uploaded by

Nalex Gee

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 156

PUBLICLY

IEC
AVAILABLE
PAS 62405
SPECIFICATION

Pre-Standard First edition

2005-06

Real-time Ethernet Vnet/IPTM specification

Reference number
IEC/PAS 62405:2005(E)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Provided by IHS under license with IEC Licensee=Daewoo Corporation/5908861001
No reproduction or networking permitted without license from IHS Not for Resale, 06/13/2006 23:28:47 MDT
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.

Further information on IEC publications

The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:

• IEC Web Site (www.iec.ch)

• Catalogue of IEC publications

The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.

• IEC Just Published

This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.

• Customer Service Centre

If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: [email protected]
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Pre-Standard First edition

2005-06

Real-time Ethernet Vnet/IPTM specification

 IEC 2005  Copyright - all rights reserved

No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.

International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: [email protected] Web: www.iec.ch

Com mission Electrotechnique Internationale

PRICE CODE
XG
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

International Electrotechnical Com m ission

Международная Электротехническая Комиссия
For price, see current catalogue

Copyright International Electrotechnical Commission

CONTENTS

FOREWORD.........................................................................................................................9

Section 1: Overview
1 Introduction ..................................................................................................................11
2 Scope and objective .....................................................................................................11
3 Structure of this document ............................................................................................11
4 Normative reference .....................................................................................................12
5 Definitions ....................................................................................................................13
5.1 Terms and definitions ..........................................................................................13
5.2 Abbreviations and symbols ..................................................................................18
5.3 Conventions ........................................................................................................20
6 Communication Profile of Vnet/IP..................................................................................21
6.1 General overview.................................................................................................21
6.2 Physical Layer .....................................................................................................22
6.3 Data Link Layer ...................................................................................................22
6.4 Network Layer .....................................................................................................23
6.5 Transport Layer ...................................................................................................23
6.6 Application Layer .................................................................................................24

Section 2: Application Layer Service definition

7 Concepts ......................................................................................................................25
7.1 General ...............................................................................................................25
7.2 Relationships between ASEs ...............................................................................25
7.3 FAL ASEs............................................................................................................25
7.4 Common FAL service parameters ........................................................................26
8 ASEs............................................................................................................................26
8.1 Variable ASE .......................................................................................................26
8.2 Event ASE...........................................................................................................30
8.3 Load Region ASE ................................................................................................32
8.4 Function Invocation ASE ......................................................................................35
8.5 Time ASE ............................................................................................................37
8.6 Network Management ASE ..................................................................................40
8.7 Application Relationship ASE ...............................................................................44
9 ARs..............................................................................................................................53
9.1
General ...............................................................................................................53
9.2
Point-to-point user-Triggered Confirmed client/server AREP (PTC-AR) .................53
9.3
Point-to-point user-Triggered Unconfirmed client/server AREP (PTU-AR)..............55
9.4
Point-to-point network-Scheduled Unconfirmed publisher/subscriber AREP
(PSU-AR) ............................................................................................................56
9.5 Multipoint user-Triggered Unconfirmed publisher/subscriber AREP (MTU-AR) .......58
9.6 Multipoint network-Scheduled Unconfirmed publisher/subscriber AREP
(MSU-AR)............................................................................................................59
10 Summary of FAL classes ..............................................................................................60
11 Permitted FAL services by AREP role ...........................................................................61
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Section 3: Application Layer protocol specification

12 Abstract syntax.............................................................................................................62
12.1 FAL PDU abstract syntax .....................................................................................62
12.2 Abstract syntax of PDU Body ...............................................................................62
12.3 PDUs for ASEs ....................................................................................................64
12.4 Type definitions ...................................................................................................67
12.5 Data types ...........................................................................................................70
13 Transfer syntax ............................................................................................................72
13.1 Overview of encoding ..........................................................................................72
13.2 APDU Header encoding .......................................................................................72
13.3 APDU Body encoding ..........................................................................................73
13.4 Data type encoding rules .....................................................................................74
14 FAL protocol state machines structure ..........................................................................78
15 AP-Context state machine ............................................................................................79
16 FAL Service Protocol Machines (FSPMs) ......................................................................79
16.1 General ...............................................................................................................79
16.2 Common parameters of the primitives ..................................................................79
16.3 Variable ASE Protocol Machine (VARM)...............................................................80
16.4 Event ASE Protocol Machine (EVTM) ...................................................................83
16.5 Load Region ASE Protocol Machine (LDRM) ........................................................85
16.6 Function Invocation ASE Protocol Machine (FNIM) ...............................................87
16.7 Time ASE Protocol Machine (TIMM) .....................................................................91
16.8 Network Management ASE Protocol Machine (NWMM) .........................................94
17 Application Relationship Protocol Machines (ARPMs) ....................................................97
17.1 General ...............................................................................................................97
17.2 Primitive definitions .............................................................................................98
17.3 State machine .....................................................................................................98
17.4 Functions .......................................................................................................... 106
18 DLL Mapping Protocol Machine (DMPM) ..................................................................... 107
18.1 General ............................................................................................................. 107
18.2 Primitive definitions ........................................................................................... 108
18.3 DMPM state machine ......................................................................................... 109

Part 4: Data Link Service definition

19 Overview .................................................................................................................... 112
19.1 General ............................................................................................................. 112
19.2 Overview of network structure ............................................................................ 112
19.3 Overview of addressing ..................................................................................... 113
19.4 Types of Data Link Service ................................................................................ 113
20 DLSAP management service....................................................................................... 113
20.1 Overview ........................................................................................................... 113
20.2 Facilities of the DLSAP management service...................................................... 113
20.3 Model of the DLSAP management service .......................................................... 114
20.4 Sequence of primitives at one DLSAP ................................................................ 114
20.5 Create ............................................................................................................... 115
20.6 Delete ............................................................................................................... 116
20.7 Bind .................................................................................................................. 117

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

20.8 Unbind .............................................................................................................. 119

21 Connectionless-mode Data Link Service ..................................................................... 119
21.1 Overview ........................................................................................................... 119
21.2 Facilities of the Connectionless-mode Data Link Service .................................... 120
21.3 Model of the Data Link Service .......................................................................... 120
21.4 Quality of service............................................................................................... 121
21.5 Sequence of primitives ...................................................................................... 123
21.6 Connectionless-mode function ........................................................................... 124
21.7 Types of primitives and parameters.................................................................... 124
22 DL-management Service............................................................................................. 125
22.1 Scope and inheritance ....................................................................................... 125
22.2 Facilities of the DL-management service ............................................................ 126
22.3 Model of the DL-management service ................................................................ 126
22.4 Constraints on sequence of primitives ................................................................ 126
22.5 Set .................................................................................................................... 126
22.6 Get.................................................................................................................... 127
22.7 Action................................................................................................................ 128
22.8 Event ................................................................................................................ 129
23 Overview of the DL-protocol........................................................................................ 130
23.1 General ............................................................................................................. 130
23.2 Characteristics of the protocol............................................................................ 130
23.3 Data Link Layer architecture .............................................................................. 130
23.4 Services provided by the DLL ............................................................................ 131
23.5 Network sharing with other protocols.................................................................. 133
24 DLPDU-parameter structure and encoding .................................................................. 133
24.1 Overview ........................................................................................................... 133
24.2 DLPDU common header format .......................................................................... 134
24.3 DLPDU body format ........................................................................................... 135
25 Local parameters and resources ................................................................................. 139
25.1 General ............................................................................................................. 139
25.2 Parameters and resources related to network structure ...................................... 140
25.3 Parameters and resources to support real-time data transfer .............................. 141
25.4 Parameters and resources to support the scheduling function............................. 142
25.5 Parameters and resources to support the security function ................................. 143
26 DL-service elements of procedure ............................................................................... 144
26.1 Unacknowledged Unitdata transfer Service (UUS) .............................................. 144
26.2 Acknowledged Unitdata transfer Service (AUS) .................................................. 144
26.3 Acknowledged Sequence of unitdata transfer Service (ASS) ............................... 144
26.4 Multipoint Unitdata transfer Service (MUS) ......................................................... 145
26.5 Multipoint Sequence of unitdata transfer Service (MSS)...................................... 145
27 DL-support protocol .................................................................................................... 146
27.1 Transmission scheduling.................................................................................... 146
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

27.2 Redundancy ...................................................................................................... 147

27.3 DLPDU authentication ....................................................................................... 149

Copyright International Electrotechnical Commission

Figure 1 – FAL ASEs ..........................................................................................................25

Figure 2 – The AR ASE conveys APDUs between APs ........................................................45
Figure 3 – APDU overview ..................................................................................................72
Figure 4 – Type Field ..........................................................................................................73
Figure 5 – Identifier Octet 73
Figure 6 – Length octet (one-octet format) ...........................................................................74
Figure 7 – Length octets (three-octet format) .......................................................................74
Figure 8 – Relationships among protocol machines and adjacent layers ...............................78
Figure 9 – State transition diagram of VARM .......................................................................81
Figure 10 – State transition diagram of EVTM......................................................................84
Figure 11 – State transition diagram of LDRM .....................................................................86
Figure 12 – State transition diagram of FNIM.......................................................................88
Figure 13 – State transition diagram of TIMM ......................................................................92
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Figure 14 – State transition diagram of NWMM ....................................................................95

Figure 15 – State transition diagram of the PTC-ARPM........................................................99
Figure 16 – State transition diagram of the PTU-ARPM...................................................... 101
Figure 17 – State transition diagram of the PSU-ARPM ..................................................... 102
Figure 18 – State transition diagram of the MTU-ARPM ..................................................... 104
Figure 19 – State transition diagram of the MSU-ARPM ..................................................... 105
Figure 20 – State transition diagram of DMPM ................................................................... 109
Figure 21 – Sequence of primitives for the DLSAP management DLS................................. 115
Figure 22 – Summary of DL-connectionless-mode service primitive time-sequence
diagrams .......................................................................................................................... 123
Figure 23 – State transition diagram for sequences of connectionless-mode primitives
at one DLSAP ................................................................................................................... 124
Figure 24 – Sequence of primitives for the DLM action service........................................... 126

Table 1 – Concept of DL/AL to separate service and protocol parts ......................................12

Table 2 – Conventions used for AE state machine definitions...............................................20
Table 3 – Conventions used for protocol procedure definitions ............................................21
Table 4 – OSI layers and Vnet/IP layers ..............................................................................22
Table 5 – Overview of Vnet/IP profile ..................................................................................22
Table 6 – Transport Layer Parameter selection....................................................................24
Table 7 – Read service parameters .....................................................................................28
Table 8 – Write service parameters .....................................................................................29
Table 9 – Information Report service parameters.................................................................29
Table 10 – Event Notification service parameters ................................................................31
Table 11 – Event Notification Recovery service parameters .................................................32
Table 12 – Download service parameters ............................................................................34
Table 13 – Upload service parameters ................................................................................34
Table 14 – Start service parameters ....................................................................................36
Table 15 – Stop service parameters ....................................................................................36
Table 16 – Resume service parameters...............................................................................37
Table 17 – Get Network Time service parameters ................................................................39

Copyright International Electrotechnical Commission

Table 18 – Set Network Time service parameters ................................................................39

Table 19 – Set Network Time service parameters ................................................................40
Table 20 – Get Network Status service parameters..............................................................41
Table 21 – Get Station Status service parameters ...............................................................42
Table 22 – Network Status Change Report service parameters ............................................43
Table 23 – Station Status Change Report service parameters ..............................................43
Table 24 – Conveyance of service primitives by AREP role ..................................................45
Table 25 – Valid combinations of AREP roles involved in an AR ..........................................46
Table 26 – AR-Unconfirmed Send .......................................................................................49
Table 27 – AR-Confirmed Send ...........................................................................................50
Table 28 – AR-Establish service..........................................................................................52
Table 29 – AR-Abort ...........................................................................................................53
Table 30 – FAL class summary ...........................................................................................61
Table 31 – FAL services by AR type ....................................................................................61
Table 32 – Encoding of FalArHeader Field ..........................................................................72
Table 33 – Primitives exchanged between FAL user and VARM ...........................................80
Table 34 – Parameters used with primitives exchanged FAL user and VARM .......................80
Table 35 – VARM state table – Sender transitions ...............................................................81
Table 36 – VARM state table – Receiver transitions.............................................................82
Table 37 – Functions used by the VARM .............................................................................83
Table 38 – Primitives exchanged between FAL user and EVTM ...........................................83
Table 39 – Parameters used with primitives exchanged FAL user and EVTM .......................83

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Table 40 – EVTM state table – Sender transitions ...............................................................84
Table 41 – EVTM state table – Receiver transitions .............................................................84
Table 42 – Functions used by the EVTM .............................................................................84
Table 43 – Primitives exchanged between FAL user and LDRM ...........................................85
Table 44 – Parameters used with primitives exchanged FAL user and LDRM .......................85
Table 45 – LDRM state table – Sender transitions ...............................................................86
Table 46 – LDRM state table – Receiver transitions .............................................................87
Table 47 – Functions used by the LDRM .............................................................................87
Table 48 – Primitives exchanged between FAL user and FNIM ............................................88
Table 49 – Parameters used with primitives exchanged FAL user and FNIM.........................88
Table 50 – FNIM state table – Sender transitions.................................................................89
Table 51 – FNIM state table – Receiver transitions ..............................................................89
Table 52 – Functions used by the FNIM ..............................................................................91
Table 53 – Primitives exchanged between FAL user and TIMM ............................................91
Table 54 – Parameters used with primitives exchanged FAL user and TIMM ........................91
Table 55 – TIMM states ......................................................................................................92
Table 56 – TIMM state table – Sender transitions ................................................................92
Table 57 – TIMM state table – Receiver transitions..............................................................93
Table 58 – Functions used by the TIMM ..............................................................................94
Table 59 – Primitives exchanged between FAL user and NWMM..........................................94
Table 60 – Parameters used with primitives exchanged FAL user and NWMM ......................95

Copyright International Electrotechnical Commission

Table 61 – NWMM states ....................................................................................................95

Table 62 – NWMM state table – Sender transitions ..............................................................96
Table 63 – NWMM state table – Receiver transitions ...........................................................96
Table 64 – Functions used by the NWMM............................................................................97
Table 65 – Primitives exchanged between FSPM and ARPM................................................98
Table 66 – Parameters used with primitives exchanged FSPM user and ARPM ....................98
Table 67 – PTC-ARPM states..............................................................................................99
Table 68 – PTC-ARPM state table – Sender transitions .......................................................99
Table 69 – PTC-ARPM state table – Receiver transitions ................................................... 100
Table 70 – PTU-ARPM states............................................................................................ 101
Table 71 – PTU-ARPM state table – Sender transitions ..................................................... 101
Table 72 – PTU-ARPM state table – Receiver transitions ................................................... 102
Table 73 – PSU-ARPM states ........................................................................................... 102
Table 74 – PSU-ARPM state table – Sender transitions ..................................................... 103
Table 75 – PSU-ARPM state table – Receiver transitions................................................... 103
Table 76 – MTU-ARPM states ........................................................................................... 104
Table 77 – MTU-ARPM state table – Sender transitions ..................................................... 104
Table 78 – MTU-ARPM state table – Receiver transitions .................................................. 105
Table 79 – MSU-ARPM states ........................................................................................... 105
Table 80 – MSU-ARPM state table – Sender transitions..................................................... 106
Table 81 – MSU-ARPM state table – Receiver transitions .................................................. 106
Table 82 – Functions used by the ARPMs ......................................................................... 107
Table 83 – Primitives exchanged between DMPM and ARPM............................................. 108
Table 84 – Primitives exchanged between Data Link Layer and DMPM .............................. 108
Table 85 – DMPM states ................................................................................................... 109
Table 86 – DMPM state table – Sender transitions............................................................. 109
Table 87 – DMPM state table – Receiver transitions .......................................................... 111
Table 88 – Functions used by the DMPM........................................................................... 111
Table 89 – Summary of DLSAP management primitives and parameters ............................ 114
Table 90 – DLSAP-management CREATE primitive and parameters .................................. 115
Table 91 – DLSAP-management DELETE primitive and parameters ................................... 116
Table 92 – DLSAP management BIND primitive and parameters ........................................ 117
Table 93 – DLSAP management UNBIND primitive and parameter ..................................... 119
Table 94 – Data delivery features of each type of service .................................................. 121
Table 95 – Summary of DL-connectionless-mode primitives and parameters ...................... 123
Table 96 – DL-connectionless-mode UNITDATA transfer primitives and parameters ........... 124
Table 97 – Summary of DL-management primitives and parameters................................... 126
Table 98 – DLM-SET primitive and parameters .................................................................. 127
Table 99 – DLM-GET primitive and parameters ................................................................. 127
Table 100 – DLM-ACTION primitive and parameters .......................................................... 128
Table 101 – DLM-EVENT primitive and parameters ........................................................... 129
Table 102 – Referenced standards for the layers ............................................................... 131
Table 103 – Bit Positions .................................................................................................. 134
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 104 – Common Header format ................................................................................. 135

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 105 – DLPDU Types ................................................................................................ 135

Table 106 – Service subtype and PDU type of DLPDUs ..................................................... 136
Table 107 – UUS_DT_PDU ............................................................................................... 136
Table 108 – AUS_DT_PDU ............................................................................................... 137
Table 109 – AUS_RSP_PDU ............................................................................................. 137
Table 110 – ASS_DT_PDU ............................................................................................... 138
Table 111 – ASS_ENQ_PDU............................................................................................. 138
Table 112 – ASS_RSP_PDU ............................................................................................. 138
Table 113 – MUS_DT_PDU............................................................................................... 139
Table 114 – MSS_DT_PDU ............................................................................................... 139
Table 115 – Parameters and resources for the network structure ....................................... 140
Table 116 – Ranges of parameters for the network structure.............................................. 141
Table 117 – Parameters and resources real-time data transfer .......................................... 141
Table 118 – Ranges of parameters for real-time data transfer ............................................ 141
Table 119 – Parameters and resources for scheduling function .......................................... 142
Table 120 – Ranges of parameters for scheduling ............................................................. 143
Table 121 – Parameters and resources for security function .............................................. 143
Table 122 – Ranges of parameters for security function..................................................... 143
Table 123 – UUS Procedure.............................................................................................. 144
Table 124 – AUS Procedure .............................................................................................. 144
Table 125 – ASS Procedure .............................................................................................. 145
Table 126 – MUS Procedure ............................................................................................ 145
Table 127 – MSS Procedure ............................................................................................. 146

Copyright International Electrotechnical Commission

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________

Real-time Ethernet Vnet/IPTM specification

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.

The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance
with this document may involve the use of a patent concerning Vnet/IP 1.

The Vnet/IP has the patent applications listed below:

PCT Application No. PCT/JP2004/011537

PCT Application No. PCT/JP2004/011538.

IEC takes no position concerning the evidence, validity and scope of this patent right.

The holder of this patent right has assured the IEC that he is willing to negotiate licences under reasonable and
non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the
holder of this patent right is registered with IEC. Information may be obtained from:

Yokogawa Electric Corporation

Intellectual Property & Standardization Center
2-9-32 Nakacho, Musashino-shi, 180-8750
Tokyo, Japan.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights
other than those identified above. IEC shall not be held responsible for identifying any or all such patent rights.

———————
1 Vnet/IP is the trade name of Yokogawa Electric Corporation. This information is given for the convenience of
users of this PAS and does not constitute an endorsement by IEC of the trademark holder or any of its products.
Compliance to this profile does not require use of the trade name Vnet/IP. Use of the trade name Vnet/IP
requires permission of the Yokogawa Electric Corporation.

Copyright International Electrotechnical Commission

A PAS is a technical specification not fulfilling the requirements for a standard but made
available to the public .

IEC-PAS 62405 has been processed by subcommittee 65C: Digital communications, of IEC
technical committee 65: Industrial-process measurement and control.

The text of this PAS is based on the This PAS was approved for
following document: publication by the P-members of the
committee concerned as indicated in
the following document
Draft PAS Report on voting
65C/352/NP 65C/369/RVN

Following publication of this PAS, the technical committee or subcommittee concerned will
transform it into an International Standard.

It is intended that the content of this PAS will be incorporated in the future new edition of the
various parts of IEC 61158 series according to the structure of this series.

This PAS shall remain valid for an initial maximum period of three years starting from
2005-06. The validity may be extended for a single three-year period, following which it shall
be revised to become another type of normative document or shall be withdrawn.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Real-time Ethernet Vnet/IPTM specification

Section 1: Overview

This PAS has been divided into five sections.

Section 1: Overview
Section 2: Application Layer Service definition
Section 3: Application Layer protocol specification
Section 4: Data Link Layer Service definition
Section 5: Data Link Layer protocol specification

1 Introduction

The Vnet/IP is designed for highly reliable real-time communication, and applies to the
operation of process control systems. The process control system consists of many
controllers, human-machine interfaces, process monitors, and gateways to external networks
which are connected to Ethernet-based IP networks. The data transfer between these devices
is performed by peer-to-peer or multicast communication.

It is required that the process control system responds within a deterministic time. At the
same time, it is also required that multi-vendor's multi-devices can be connected to the same
IP network. For example, the process control system shall handle operational signals for the
actuator within a determined time and needs to communicate with other devices connected to
Ethernet-based IP networks to exchange non-realtime information such as files and images.

The Vnet/IP realizes these two conflicting requirements on the same network using a unique
technology as described in this PAS.

2 Scope and objective

This PAS describes the communication profile of the whole Vnet/IP, services of each layer
and the specifications of the protocols for each layer.

3 Structure of this document

Section 1 of this PAS presents an overview of and guidance for the Vnet/IP Specification. It
also explains the structure and content of the Vnet/IP Specification and shows how to use
each section of the document. In addition, it specifies the communication profile of the Vnet/IP.

Sections 2 and 3 present the Vnet/IP Specification for the Application Layer, and Sections 4
and 5 for the Data Link Layer. This PAS refers the appropriate international standards for the
specifications of other layers.

The Data Link and Application Layers are described in complementary ways, in terms of the
services offered and the protocol which provides those services.

Table 1 shows the differences between service and protocol viewpoints of the Data Link and
Application Layers. The protocol parts show the layer implementer’s view and the service
parts show the layer user’s view.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 1 – Concept of DL/AL to separate service and protocol parts

Layer user Oriented view Layer implementer Oriented view

AL Services (Section 2 of this PAS) AL Protocol (Section 3 of this PAS)
- Model and concepts - Syntax definition and coding
- Data type definitions - Application relationships procedures
- Application objects - Protocol machines (state machines)
- Service description
- Communication endpoint management.
DL Services (Section 4 of this PAS) DL Protocol (Section 5 of this PAS)
- Model and concepts - Coding
- Service description - Protocol machines (state machines)
- Management services

The Application Layer structure is as follows:

• “What” is described by Application Service Elements (ASE); and

• “How” is described by Application Relationships (AR).

The Data Link Layer structure is as follows:

• “What” is described by Data Link services and models; and

• “How” is described by Data Link protocol machines and medium access principles.

4 Normative reference

The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For all other undated references, the
latest edition of the referenced document (including any amendments) applies.

IEC 61158-1:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 1: Overview and guidance for the IEC 61158 series

IEC 61158-3:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 3: Data link service definition

IEC 61158-4:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 4: Data link protocol specification

IEC 61158-5:2003, Digital data communications for measurement and control – Fieldbus for
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

use in industrial control systems – Part 5: Application layer service definition

IEC 61158-6:2003, Digital data communications for measurement and control – Fieldbus for
use in industrial control systems – Part 6: Application layer protocol specification

ISO/IEC 7498 (all parts), Information technology – Open Systems Interconnection – Basic
Reference Model

ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic reference

model – Conventions for the definition of OSI services

ISO/IEC 9545:1994, Information technology – Open Systems Interconnection – Application

Layer structure

ISO/IEC 8824-2:2002, Information technology – Abstract Syntax Notation One (ASN.1):

Information object specification

ISO/IEC 8825-1:2002, Information technology – ASN.1 encoding rules: Specification of Basic

Encoding Rules (BER), Canonical Encoding RUles (CER) and Distinguished Encoding RUles
(DER)

Copyright International Electrotechnical Commission

ISO/IEC 8802-0:2000, Information technology – Telecommunications and information

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

exchange between systems – Local and metropolitan area networks - Specific requirements –
Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and
physical layer specifications

Internet Engineering Task Force (IETF), Request for Comments (RFC):

RFC 768 User Datagram Protocol

(available at <http://www.ietf.org/rfc/rfc0768.txt>)
RFC 791 Internet Protocol
(available at <http://www.ietf.org/rfc/rfc0791.txt>)
RFC 792 Internet Control Message Protocol
(available at <http://www.ietf.org/rfc/rfc0792.txt>)
RFC 826 Ethernet Address Resolution Protocol
(available at <http://www.ietf.org/rfc/rfc0826.txt>)
RFC 894 A standard for the Transmission of IP Datagrams over Ethernet Networks
(available at <http://www.ietf.org/rfc/rfc0894.txt>)
RFC 1112 Host Extensions for IP Multicasting
(available at <http://www.ietf.org/rfc/rfc1112.txt>)
RFC 2236 Internet Group Management Protocol Version 2
(available at <http://www.ietf.org/rfc/rfc2236.txt>)

5 Definitions

For the purposes of this document, the following terms and definitions apply.

5.1 Terms and definitions

5.1.1 ISO/IEC 7498-1 terms

For the purposes of this document, the following terms as defined in ISO/IEC 7498-1 apply:

1) application entity
2) application protocol data unit
3) application service element

5.1.2 ISO/IEC 8824-2 terms

For the purposes of this document, the following terms as defined in ISO/IEC 8824 apply:

1) any type
2) bitstring type
3) Boolean type
4) choice type
5) false
6) integer type
7) null type
8) octetstring type
9) sequence of type
10) sequence type
11) simple type
12) structured type
13) tagged type
14) true
15) type
16) value

Copyright International Electrotechnical Commission

5.1.3 ISO/IEC 10731 terms

1) (N)-connection
2) (N)-entity
3) (N)-layer
4) (N)-service
5) (N)-service-access-point
6) application-service-object
7) confirm (primitive)
8) deliver (primitive)
9) indication (primitive)
10) OSI-confirmed-facility
11) OSI-facility
12) OSI-local view
13) OSI-mandatory-facility
14) OSI-non-confirmed-facility
15) OSI-provider-initiated-facility
16) OSI-provider-optional-facility
17) OSI-service
18) OSI-service primitive; primitive
19) OSI-service-provider
20) OSI-service-user
21) OSI-user-optional-facility
22) request (primitive)
23) response (primitive)
24) submit (primitive)

5.1.4 IEC 61158-3 and IEC 61158-4 terms

For the purposes of this document, the following terms as defined in IEC 61158-3 and IEC
61158-4 apply.

1) DL-Time
2) DL-Scheduling-policy
3) DL-connection-oriented mode
4) fixed tag
5) generic tag
6) link
7) MAC ID
8) network address
9) node address
10) node
11) tag
12) scheduled
13) unscheduled

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

5.1.5 IEC 61158-5 terms

For the purposes of this document, the following terms as defined in IEC 61158-5 apply.

1) active connection control object

2) application
3) application objects
4) application process
5) application process identifier
6) application relationship
7) application relationship application service element
8) application relationship endpoint
9) attribute
10) behaviour
11) channel
12) class
13) client
14) connection
15) connection point
16) conveyance path
17) cyclic
18) dedicated AR
19) device
20) end node
21) endpoint
22) error
23) error class
24) event
25) group
26) instance
27) instantiated
28) interface
29) invocation
30) management information
31) method
32) network
33) object
34) originator
35) peer
36) produce
37) producer
38) provider
39) publisher
40) resource
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

41) server
42) service
43) slot
44) subscriber
45) sync

5.1.6 IEC 61158-6 terms

For the purposes of this document, the following terms as defined in IEC 61158-6 apply.

1) called
2) calling
3) receiving
4) sending

5.1.7 Other terms and definitions

5.1.7.1 Vnet/IP Network

a network that is compliant with the Vnet/IP specification, which consists of one or more
domains. The domains are connected to each other by routers. In a redundant Vnet/IP
network structure, the Vnet/IP network consists of two networks; a primary network and a
secondary network
NOTE The primary network and the secondary network are independent and are not connected to each other.

5.1.7.2 domain

a part of the Vnet/IP network consisting of one or two subnetwork(s)

NOTE Two subnetworks are required to compose a dual-redundant Vnet/IP network, and each end node in the
domain is connected to both of the subnetworks.

5.1.7.3 subnetwork

a part of a network that does not contain any routers. A subnetwork consists of end nodes,
bridges and segments
NOTE Every end node included in a subnetwork has the same IP network address.

5.1.7.4 router

intermediate equipment that connects two or more subnetworks using a network layer relay
function

5.1.7.5 route

a logical communication channel between two communication end nodes

5.1.7.6 segment

a communication channel that connects two nodes directly without intervening bridges

5.1.7.7 bridge

intermediate equipment that connects two or more segments using a Data Link layer relay
function

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

5.1.7.8 internal bridge

a bridge to which no routers, external bridges or nodes non-compliant with this specification
are connected directly

5.1.7.9 junction bridge

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
a bridge to which at least one router, external bridge or node non-compliant with this
specification, and to which at least one internal bridge or Vnet/IP station is connected

5.1.7.10 external bridge

a bridge to which neither internal bridges nor Vnet/IP stations are connected directly

5.1.7.11 station

an end node or a pair of end nodes that perform a specific application function

5.1.7.12 Vnet/IP station

a station compliant with this specification

5.1.7.13 redundant station

a station that consists of a pair of end nodes

NOTE Each end node of a redundant station has the same station number, but has a different DL-address.

5.1.7.14 non-redundant station

a station that consists of a single end node

NOTE “non-redundant station” is synonymous with “end node”.

5.1.7.15 link

a physical communication channel between two nodes

5.1.7.16 path

a logical communication channel between two nodes, which consists of one or two link(s)

5.1.7.17 interface port

a physical connection point of an end node, which has an independent DL-address

5.1.7.18 redundant interface node

a node with two interface ports one of which is connected to a primary network, while the
other is connected to a secondary network

5.1.7.19 non-redundant interface node

a node whch has a single interface port

5.1.7.20 domain master

a station which performs diagnosis of routes to all other domains, distribution of network time
to nodes inside the domain, acquisition of absolute time from the network time master and
notification of status of the domain

Copyright International Electrotechnical Commission

5.1.7.21 network time master

a station which distributes network time to domain masters

5.1.7.22 domain number

a numeric identifier which indicates a domain

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
5.1.7.23 station number

a numeric identifier which indicates a Vnet/IP station

5.2 Abbreviations and symbols

5.2.1 ISO/IEC 10731 abbreviations

ASE application-service-element
ASO application-service-object
OSI Open Systems Interconnection

5.2.2 IEC 61158-3 abbreviations and symbols

DL- Data Link layer (as a prefix)
DLE DL-entity (the local active instance of the Data Link layer)
DLL DL-layer
DLM DL-management
DLMS DL-management Service
DLPDU DL-protocol-data-unit
DLS DL-service
DLSAP DL-service-access-point
DLSDU DL-service-data-unit
FIFO First-in first-out (queuing method)
QoS Quality of service

5.2.3 IEC 61158-4 abbreviations and symbols

LLC logical link control
MAC medium access control
Ph- physical layer (as a prefix)
PhL Ph-layer

5.2.4 IEC 61158-5 abbreviations and symbols

ACCO Active Connection Control Object
AE Application Entity
AL Application Layer
ALP Application Layer Protocol
AP Application Process
Ap_ Prefix for Data types defined for AP ASE
APDU Application Protocol Data Unit
API Application Process Identifier
APO Application Object
AR Application Relationship

Copyright International Electrotechnical Commission

AREP Application Relationship End Point

ASN.1 Abstract Syntax Notation One
BCD Binary Coded Decimal
BER Basic Encoding Rule
CID Connection ID
CIM Computer Integrated Manufacturing
Cnf Confirmation
cnf confirmation primitive
Dl_ Prefix for Data types defined for Data Link Layer types DL Data Link
Dt_ Prefix for Data types defined for Data Type ASE
Er_ Prefix for Error types defined
Err Error (used to indicate an APDU type)
Ev_ Prefix for Data types defined for Event ASE
FAL Fieldbus Application Layer
Gn_ Prefix for Data Types defined for general use
ID Identifier
IEC International Electrotechnical Commission
Ind Indication
ind indication primitive
IP Internet Protocol
ISO International Organization for Standardization
lsb least significant bit
msb most significant bit
out output primitive
PDU Protocol Data Unit
PL Physical Layer
Req Request
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

req request primitive

Rsp Response
rsp response primitive
SAP Service Access Point
SDU Service Data Unit
ToS Type Of Service

5.2.5 Vnet/IP abbreviations and symbols

ARPM Application Relationship Protocol Machine
ASS Acknowledged Sequence of unitdata transfer Service
AUS Acknowledged Unitdata transfer Service
FSPM FAL Service Protocol Machine
MSS Multipoint Sequence of unitdata transfer Service
MSU-AR Multipoint network-Scheduled Unconfirmed publisher/subscriber AREP
MTU-AR Multipoint user-Triggered Unconfirmed publisher/subscriber AREP
MUS Multipoint Unitdata transfer Service

Copyright International Electrotechnical Commission

PSU-AR Point-to-point network-Scheduled Unconfirmed client/server AREP

PTC-AR Point-to-point user-Triggered Confirmed client/server AREP
PTU-AR Point-to-point user-Triggered Unconfirmed client/server AREP
UUS Unacknowledged Unitdata transfer Service

5.3 Conventions

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
5.3.1 General conventions

This PAS uses the descriptive conventions given in ISO/IEC 10731.

5.3.2 Conventions for communication profile definitions

This PAS uses the descriptive conventions given in IEC 61784 for communication profile
definitions.

5.3.3 Conventions for class definitions

This PAS uses the descriptive conventions given in IEC 61158-5 for class definitions.

5.3.4 Conventions for FAL service definitions

This PAS uses the descriptive conventions given in IEC 61158-5 for FAL service definitions.

5.3.5 Conventions for APDU abstract syntax definitions

This PAS uses the descriptive conventions given in ISO/IEC 8824-2 for APDU definitions.

5.3.6 Conventions for APDU transfer syntax definitions

This PAS uses the descriptive conventions given in ISO/IEC 8825-1 for transfer syntax definitions.

5.3.7 Conventions for AE state machine definitions

The conventions used for AE state machine definitions are described in Table 2.

Table 2 – Conventions used for AE state machine definitions

# Current state Event / condition => action Next state

Name of this The current Events or conditions that trigger this state The next state
transition. state to which transition. after the
this state => actions in this
transition The actions that are taken when the above transition are
applies. events or conditions are met. The actions are taken.
always indented below events or conditions.

The conventions used in the descriptions for the events, conditions and actions are as follows:

:= The value of an item on the left is replaced by the value of an item on the right. If an item
on the right is a parameter, it comes from the primitive shown as an input event.
xxx Parameter name.
Example:
Identifier := reason
means value of the ‘reason’ parameter is assigned to the parameter called
‘Identifier.’
“xxx” Indicates fixed value.
Example:
Identifier := “abc”
means value “abc” is assigned to a parameter named ‘Identifier.’

Copyright International Electrotechnical Commission

= A logical condition to indicate an item on the left is equal to an item on the right.
< A logical condition to indicate an item on the left is less than the item on the right.
> A logical condition to indicate an item on the left is greater than the item on the right.
<> A logical condition to indicate an item on the left is not equal to an item on the right.
&& Logical “AND”
|| Logical “OR”

The sequence of actions and the alternative actions can be executed using the following
reserved words.

for
endfor
if
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

else
elseif
The following shows examples of description using the reserved words.
Example 1:
for (Identifier := start_value to end_value)
actions
endfor
Example 2:
If (condition)
actions
else
actions
endif

5.3.8 Conventions for DLL service definitions

This standard uses the descriptive conventions given in IEC 61158-3 for DLL service
definitions.

5.3.9 Conventions for DLE protocol procedure definitions

The conventions used for DLE state machine definitions are described in Table 3.

Table 3 – Conventions used for protocol procedure definitions

Event Condition Procedure

Events that trigger Conditions Actions that are taken when the events and conditions
these actions are met .

6 Communication Profile of Vnet/IP

6.1 General overview

The Vnet/IP protocol is described using the principles, methodology and model of ISO/IEC
7498. In addition, it also follows the three-layer basic fieldbus reference model described in
the IEC 61158-1.

The OSI model provides a layered approach to communication standards, whereby the layers
can be developed and modified independently. The Vnet/IP communication profile is based on
the three-layer structure, and each layer of OSI seven layers is mapped onto these three
layers as follows.

Copyright International Electrotechnical Commission

Functions of the intermediate OSI layers, layers 5 – 6, are consolidated into the Application
Layer.

Functions of the intermediate OSI layers, layers 3 – 4, are consolidated into the Data Link
Layer.

Likewise, some features common to users of the Fieldbus Application Layer are provided to
simplify user operation.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 4 shows the OSI layers, their functions and the equivalent layers in the Vnet/IP layer
model.

Table 4 – OSI layers and Vnet/IP layers

OSI layer Function Vnet/IP layer

7 Application Translates demands placed on the communication stack into a form Application
understood by the lower layers and vice versa
6 Presentation Converts data to/from standardized network formats
5 Session Synchronizes and manages data
4 Transport Provides transparent reliable data transfer Data link
3 Network Performs message routing
2 Data link Controls access to the communication medium. Performs error
detection
1 Physical Encodes/decodes signals for transmission/reception in a form Physical
appropriate to the communication medium. Specifies communication
media characteristics.

Table 5 shows an overview of the communication profile for Vnet/IP.

Table 5 – Overview of Vnet/IP profile

Layer Protocol
Application The specification of this PAS
Transport RFC 768 and the specifications in this PAS
Network RFC 791
Data Link ISO/IEC 8802-3, -2, -10
Physical any of ISO/IEC 8802-3

6.2 Physical Layer

ISO/IEC 8802-3 shall be used.

6.3 Data Link Layer

6.3.1 MAC sublayer

ISO/IEC 8802-3 shall be used.

6.3.2 LLC sublayer

ISO/IEC 8802-3 shall be used.

Copyright International Electrotechnical Commission

6.4 Network Layer

Internet standard RFC 791 (IP, Internet Protocol) and its amendments and successors shall
be used.

6.4.1 IP Address
Unicast address
IPv4 class C private address scope shall be used. Each subnetwork of a domain has
the respective IP network address as follows.

IP address for the interface connected to the primary network :

192.168.(192+Domain number).(Host address)
IP address for the interface connected to the secondary network :
192.168.(224+Domain number).(Host address)
Each node of a redundant station has a respective IP host address as follows.
Host address: Station number or Station number + 64
Group address
IPv4 class D Organization-Local Scope shall be used as group addresses for
multicasting. Both the primary network and the secondary network of Vnet/IP network
require two group addresses: one for multicasting to all Vnet/IP stations in the domain,
and another for multicasting to all Vnet/IP stations in the Vnet/IP network.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

To assign these group addresses to the stations, AD-HOC Block group address
224.0.23.33 may be used.
NOTE This group address is registered with the Internet Assigned Numbers Authority (IANA).

6.4.2 IGMP

IGMP shall be used to perform multicasting.

6.4.3 TOS

The following five TOS parameter values shall be used for the Data Link service:

a) time synchronization
b) high priority
c) medium priority
d) low priority
e) general purpose

6.5 Transport Layer

Internet standard RFC 768 (UDP, User Datagram Protocol) and its amendments and
successors, and the Data Link Layer specified in Sections 4 and 5 of this PAS shall be used.

6.5.1 Port No

UDP port number 5313 shall be used.

NOTE This UDP port number is registered with the Internet Assigned Numbers Authority (IANA).

Copyright International Electrotechnical Commission

6.5.2 Parameter selection

Table 6 shows the parameter selection.

Table 6 – Transport Layer Parameter selection

Parameter Parameter name Usage Value

Symbol
P(ND) max-domains M 31
P(HC) max-hop-count M 7
P(NS) max-stations M 64
P(GA 1A ) IP-group-address-1A M 239.192.24.0
P(GA 1B ) IP-group-address-1B M 239.192.24.1
P(GA 2A ) IP-group-address-2A M 239.192.24.4
P(GA 2B ) IP-group-address-2B M 239.192.24.5
P(AB DA ) IP-base-address-domain-A M 192.168.0.0
P(AB DB ) IP-base-address-domain-B M 192.268.128.0
P(MRC AUS ) max-retry-count-AUS M 5
P(MRC ASS ) max-retry-count-ASS M 5
P(MOS) max-outstanding-number M 10
P(TNR AUS ) max-response-time-AUS M 50 ms
P(TNR ASS ) max-response-time-ASS M 500 ms
P(TWT AUS ) wait-time-AUS M 100 ms
P(TWT ASS ) wait-time-ASS M 100 ms
P(TID ASS ) inter-DTPDU-time M 500 ms
P(MC) macro-cycle-period M 100 ms
P(SD UUS ) starting-delay-UUS M {5,55} ms
P(SD AUS ) starting-delay-AUS M {5,55} ms
P(SD ASS ) starting-delay-ASS M {10,20,30,40,60,70,80} ms
P(SD MUS ) starting-delay-MUS M {12,32,62,82} ms
P(SD MSS ) starting-delay-MSS M {40} ms
P(TD UUS ) time-duration-UUS M 35 ms
P(TD AUS ) time-duration-AUS M 35 ms
P(TD ASS ) time-duration-ASS M 1 ms
P(TD MUS ) time-duration-MUS M 1 ms
P(TD MSS ) time-duration-MSS M 5 ms
P(TO UUS ) offset-time-UUS M 1 ms
P(TO AUS ) offset-time-AUS M 1 ms
P(TO ASS ) offset-time-ASS M 1 ms
P(TO MUS ) offset-time-MUS M 1 ms
P(TO MSS ) offset-time-MSS M 1 ms
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

P(DV UUS ) divisor-for-grouping M 5

P(DV AUS ) divisor-for-grouping M 5
P(DV ASS ) divisor-for-grouping M 8
P(DV MUS ) divisor-for-grouping M 8
P(DV MSS ) divisor-for-grouping M 1
P(KS) key size M 4
P(AS) authentication field size M 1
P(PN) prime-number M 0b01011001
P(BS) base-number M 251
P(UD) key-update-time M 3600 s

6.6 Application Layer

The Application Layer specified in Parts 2 and 3 of this document shall be used. The
specifications of Layers 5 and 6 are included in the Application Layer’s specifications of this
document.

Copyright International Electrotechnical Commission

Section 2: Application Layer Service definition

7 Concepts

7.1 General

This Fieldbus Application Layer (FAL) provides communication services to time-critical and
nontime-critical applications in fieldbus devices.

7.2 Relationships between ASEs

7.3 FAL ASEs

A modular approach was taken in the definition of FAL ASEs. The ASEs defined for the FAL
are also object-oriented. In general, ASEs provide a set of services designed for one specific
object class or for a related set of classes.

To support remote access to the AP, the Application Relationship ASE is defined. This
application relationship ASE provides services to the AP for defining and establishing
communication relationships with other APs, and provides services to other ASEs for
conveying their service requests and responses.

Each FAL ASE defines a set of services, APDUs and procedures that operate on the classes
that it represents. Only a subset of the ASE services may be provided to meet the needs of an
application. Profiles may be used to define such subsets.

APDUs are sent and received between FAL ASEs that support the same services. Figure 1 shows
the FAL ASEs from the perspective of communication.

FAL AP
APO ASE Service Primitives

Variable Event Fnc Inv Load Reg Time NW MNG APO ASEs
ASE ASE ASE ASE ASE ASE
AR ASE
Service
Primitives
AR
ASE

Example FAL AE

Conveyance of APDUs by the AR ASE

Figure 1 – FAL ASEs

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

7.4 Common FAL service parameters

Many services have the following parameters. Instead of defining them for each service, the
following common definitions are provided:

Argument
This parameter carries the parameters of the service invocation.

AREP
This parameter contains information sufficient for local identification of the AREP to be used
to convey the service. This parameter may use a key attribute of the AREP to identify the
application relationship. When an AREP supports multiple contexts simultaneously, the AREP
parameter is extended to identify the context as well as the AREP.

InvokeID
This parameter identifies this invocation of the service. InvokeID is used to associate service
requests with responses. Therefore, no two outstanding service invocations can be identified
by the same InvokeID value.

Result(+)
This selection type parameter indicates that the service request was successful.

Result(-)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
This selection type parameter indicates that the request failed.

Error Info
This parameter provides error information for service errors. It is returned in confirmed service
response(-) primitives.

8 ASEs

8.1 Variable ASE

8.1.1 Overview

In the fieldbus environment, application processes contain data that can be both read and
written by remote applications. The variable ASE defines the network-visible attributes of
application data and provides a set of services used to read, write and report their values.

When the appropriate types of application relationship are supported, the variable ASE may
be used to support two different access models i.e., the client/server model and the
publisher/subscriber model. The client/server model is characterized by a client application
sending a read or write request to a server application that responds accordingly. The server's
activity is stimulated by clients on the network; if there are no requests, the server generates
no responses.

The publisher/subscriber model is different in that it is characterized by a data producer

publishing its data onto the network. Subscribers wishing to acquire the published data join
the application relationship used to publish it and listen for the data as it is transmitted. Two
models are provided to support this publisher/subscriber activity, i.e., the “pull” model and the
“push” model.

In the “pull” model, one of the subscribers requests that the publisher publishes a sequence of
variable data by issuing a publish request to it. The publisher distributes the variable data
periodically according to the remote request by multicasting. The publishing schedule is
controlled by the publisher itself.

In the “push” model, the publisher is requested to distribute a sequence of variable data by
the local FAL user. The publisher distributes a sequence of variable data by multicasting

Copyright International Electrotechnical Commission

according to the local request. The publishing schedule is also controlled by the publisher
itself.

8.1.2 Variable class specification

8.1.2.1 Formal model

FAL ASE: VARIABLE ASE
CLASS: VARIABLE
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Key Attribute: Numeric Identifier
2 (m) Attribute: Data Type
3 (0) Attribute: Length
4 (o) Attribute: Read enable
5 (o) Attribute: Write enable
SERVICES:
1 (o) OpsService: Read
2 (o) OpsService: Write
3 (o) OpsService: Information Report

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
8.1.2.2 Attributes
Numeric Identifier
This key attribute identifies an instance of this object class.

Data Type
This attribute is the numeric identifier of the data type.

Length
This optional attribute is the length of the data in octets.

Read enable
The value of this optional attribute indicates whether the data value of the Variable Object can
be read via the fieldbus.

Write enable
The value of this optional attribute indicates whether the data value of the Variable Object can
be updated via the fieldbus.

8.1.3 Variable List class specification

8.1.3.1 Formal model

FAL ASE: VARIABLE ASE
CLASS: VARIABLE LIST
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Key Attribute: Numeric Identifier
2 (m) Attribute: Number of Entries
3 (m) Attribute: List Of Variables
SERVICES:
1 (o) OpsService: Read
2 (o) OpsService: Write
3 (o) OpsService: Information Report

8.1.3.2 Attributes
Numeric Identifier
This key attribute identifies an instance of this object class.

Number of Entries
This attribute contains the number of variables in the list.

Copyright International Electrotechnical Commission

List of Variables
This attribute identifies the variables by key attribute that are contained in the list.

8.1.4 Variable ASE service specification

8.1.4.1 Supported services

This subclause contains the definition of services that are unique to this ASE. The services
defined for this ASE are:

• Read
• Write
• Information Report

8.1.4.2 Read service

8.1.4.2.1 Service overview

This confirmed service may be used to read the value of a variable object or a variable list
object. It is not used with the publisher/subscriber model.

8.1.4.2.2 Service primitives

The service parameters for each primitive are shown in Table 7.

Table 7 – Read service parameters

Parameter name Req Ind Rsp Cnf

Argument M M(=)
AREP M M(=)
InvokeID M M(=)
Variable Specifier M M(=)
Result(+) S S(=)
AREP M M(=)
InvokeID M M(=)
Value M M(=)
Result(-) S S(=)
AREP M M(=)
InvokeID M M(=)
Error Info M M(=)

Variable Specifier
This parameter specifies a variable object or a variable list object to be read by the key
attribute.

Value
This parameter contains the value read. For each of the variables, this parameter contains the value of the variable.
For variable lists, this parameter contains the values of each of the variables in the list concatenated together in
the order in which they appear in the list.
NOTE If any of the variables in a variable list could not be read, the service fails.

8.1.4.3 Write service

8.1.4.3.1 Service overview

This confirmed service is used to write the value of a variable object or a variable list object. It
is not used with the publisher/subscriber model.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

8.1.4.3.2 Service primitives

The service parameters for each primitive are shown in Table 8.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 8 – Write service parameters

Parameter name Req Ind Rsp Cnf

Argument M M(=)
AREP M M(=)
InvokeID M M(=)
Variable Specifier M M(=)
Value M M(=)
Result(+) S S(=)
AREP M M(=)
InvokeID M M(=)
Result(-) S S(=)
AREP M M(=)
InvokeID M M(=)
Error Info M M(=)

Variable Specifier
This parameter specifies a variable object or a variable list object to be written by the key
attribute.

Value
This parameter contains the value to write. For variables, this parameter contains the value of
the variable. For variable lists, this parameter contains the values of each of the variables in
the list concatenated together in the order that they appear in the list.
NOTE If any variable in a variable list object cannot be updated, none of the variables in the variable list object
will be updated and the write will fail.

8.1.4.4 Information Report service

8.1.4.4.1 Service overview

This optional service is an unconfirmed service that may be used to report the value of a
variable object or a variable list object. This service may be used in the publisher/subscriber
push model.

8.1.4.4.2 Service primitives

The service parameters for each primitive are shown in Table 9.

Table 9 – Information Report service parameters

Parameter name Req Ind

Argument M M(=)
AREP M M(=)
Variable Specifier M M(=)
Value M M(=)

Variable Specifier
This parameter specifies a variable object or a variable list object to be reported by the key
attribute.

Copyright International Electrotechnical Commission

Value
This parameter contains the value to be reported. For variables, this parameter contains the
value of the variable. For variable lists, this parameter contains the value of each variable in
the list concatenated together in the order that they appear in the list.
NOTE If any of the variables in a variable list could not be read, the service fails.

8.2 Event ASE

8.2.1 Overview

Event objects are used to define messages reporting event occurrences. Event messages
contain information that identifies and describes event occurrences.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Notifiers are responsible for collecting event messages from event objects, and distributing
one or more event message(s) in a single invocation of the FAL event notification service. The
number of event messages that may be submitted in a single service invocation is limited by
the maximum APDU size that can be transferred by the AR.

If an application process fails to receive one or more event notifications, a notification

recovery service is provided to request the notifier to retransmit the notifications.

In this model, application processes are responsible for providing the functions for event
objects and event list objects, and the FAL is responsible for providing communication
services designed specifically for them. The application process detects events, builds event
messages and aggregates them together. The application process distributes the aggregated
event messages using the FAL event notification service.

8.2.2 Event class specification

8.2.2.1 Formal model

FAL ASE: EVENT ASE
CLASS: NOTIFIER
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Key Attribute: Numeric Identifier
2 (m) Attribute: AREP
3 (o) Attribute: Last Notification Sequence Number
4 (o) Attribute: List Of Events
SERVICES:
1 (o) OpsService: Event Notification
2 (o) OpsService: Notification Recovery

8.2.2.2 Attributes

8.2.2.2.1 Numeric Identifier

This key attribute identifies an instance of this object class.

8.2.2.2.2 AREP

This attribute identifies the AREP configured to convey event notifications. This AREP is also
used for reporting the event notifications generated by an event recovery request.

8.2.2.2.3 Last Notification Sequence Number

The conditional attribute contains the last sequence number used. It is incremented for each
event notification service invocation.

Copyright International Electrotechnical Commission

8.2.2.2.4 List of Events

This optional attribute identifies the events that are configured.

8.2.3 Event ASE service specification

8.2.3.1 Supported services

This subclause contains the definition of services that are unique to this ASE. The services
defined for this ASE are:

• Event Notification
• Notification Recovery

8.2.3.2 Event Notification service

8.2.3.2.1 Service overview

This unconfirmed service is used by the notifier of an FAL AP to notify other APs that one or
more events have occurred.

8.2.3.2.2 Service primitives

The service parameters for each primitive are shown in Table 10.

Table 10 – Event Notification service parameters

Parameter name Req Ind

Argument M M(=)
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

AREP M M(=)
NotifierID M M(=)
Sequence Number U U(=)
Notification Time U U(=)
List of Event Messages M M(=)
Event Key Attribute M M(=)
Event Data Type C C(=)
Event Detection Time U U(=)
Event Data U U(=)

NotifierID
This parameter identifies the notifier issuing the event notification.

Sequence Number
This optional parameter is the sequence number for the event notification. It may be used for
notification recovery purposes.

Notification Time
This optional parameter is the time tag for event notification.

List of Event Messages

This parameter contains the list of event messages that are to be reported. It may contain
messages from one or more event objects. The contents of each message are specified by its
event object and shall be consistent with that specified for the notifier object.

Event Key Attribute

This parameter identifies each of the specific events being acknowledged by this
service.

Copyright International Electrotechnical Commission

Event Data Type

This conditional parameter indicates the data type of each of the event data
parameters. This parameter may be present only if the event data parameter is
present. If the event data parameter is present, this parameter shall be present.

Event Detection Time

This optional parameter reports the time of the event detection. This parameter is
present only if it is defined for the specified event object and is supported by the
specified notifier.

Event Data
This optional parameter contains user data to be included in an event message in
addition to that used to identify the event occurrence. This parameter is present only if
it is defined for the specified event object and is supported by the specified notifier.

8.2.3.3 Notification Recovery service

8.2.3.3.1 Service overview

This unconfirmed service is used to request that a specified number of retained event
notifications be returned. Notifications are returned using the event notification service.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
8.2.3.3.2 Service primitives

The service parameters for each primitive are shown in Table 11.

Table 11 – Event Notification Recovery service parameters

Parameter name Req Ind

Argument M M(=)
AREP M M(=)
NotifierID M M(=)
Sequence Number U U(=)

NotifierID
This parameter identifies the notifier to which this service is directed.

Sequence Number
This optional parameter specifies the sequence number of the event notification to be re-sent.
If not present, the last notification sent is being requested.

8.3 Load Region ASE

8.3.1 Overview

A load region represents an unstructured memory area whose contents is to be uploaded

(read) or downloaded (written). In this context, “unstructured” means that the memory area is
represented only as an ordered sequence of octets. No other structure is apparent.

A load region may represent an unnamed volatile memory area, such as that implemented by
dynamic computer memory, or a named non-volatile memory object, such as a file. The
contents of a load region are referred to as a load image and can contain programs or data.
The transfer of a load image to or from a load region is performed using the load process.

This load region model provides services that permit an application process to initiate the
downloading or uploading of specified load regions.

Copyright International Electrotechnical Commission

8.3.2 Load Region class specification

8.3.2.1 Formal model

FAL ASE: LOAD REGION ASE
CLASS: LOAD REGION
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Attribute: Load Region Size

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
2 (m) Attribute: Local Address
3 (o) Attribute: Load Image Name
SERVICES:
1 (m) OpsService: Download Services
2 (m) OpsService: Upload Services

8.3.2.2 Attributes
Load Region Size
This attribute specifies the maximum size of the load region in octets.

Local Address
This attribute is a locally significant address of the load region.

Load Image Name

This optional attribute specifies the name of the load image contained in the load region.

8.3.3 Load Region ASE service specification

8.3.3.1 Supported services

This subclause contains the definitions of services that are unique to this ASE. The services
defined for this ASE are:

• Download
• Upload

8.3.3.2 Download service

8.3.3.2.1 Service overview

This confirmed service is used to download a load image in its request and indication
primitives. The response and confirmation primitives are used to convey the success or failure
of the download.

8.3.3.2.2 Service primitives

The service parameters for each primitive are shown in Table 12.

Copyright International Electrotechnical Commission

Table 12 – Download service parameters

Parameter name Req Ind Rsp Cnf

Argument M M(=)
AREP M M(=)
InvokeID M M(=)
Load Region M M(=)
Load Data M M(=)
Result(+) S S(=)
AREP M M(=)
InvokeID M M(=)
Result(-) S S(=)
AREP M M(=)
InvokeID M M(=)
Error Info M M(=)

Load Region
This parameter specifies the load region into which the image is to be downloaded.

Load Data
This parameter contains the data to be downloaded.

8.3.3.3 Upload service

8.3.3.3.1 Service overview

This confirmed service is used to upload a load image. Its request and indication primitives
convey an upload request. The response and confirmation primitives are used to convey the
load image of the load region and the result of loading.

8.3.3.3.2 Service primitives

The service parameters for each primitive are shown in Table 13.

Table 13 – Upload service parameters

Parameter name Req Ind Rsp Cnf

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Argument M M(=)
AREP M M(=)
InvokeID M M(=)
Load Region M M(=)
Result(+) S S(=)
AREP M M(=)
InvokeID M M(=)
Load Data M M(=)
Result(-) S S(=)
AREP M M(=)
InvokeID M M(=)
Error Info M M(=)

Copyright International Electrotechnical Commission

Load Region
This parameter specifies the load region from which the image is to be uploaded.

Load Data
This parameter contains the data uploaded.

8.4 Function Invocation ASE

8.4.1 Overview
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

The function invocation class models the state-oriented function invocation. It may be used to
model software processes or user functions the operation of which may be controlled.

8.4.2 Function Invocation class specification

8.4.2.1 Formal model

FAL ASE: FUNCTION INVOCATION ASE
CLASS: FUNCTION INVOCATION
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Key Attribute: Identifier
2 (m) Attribute: Function Invocation State
SERVICES:
1 (o) OpsService: Start
2 (o) OpsService: Stop
3 (o) OpsService: Resume

8.4.2.2 Attributes

8.4.2.2.1 Identifier

This key attribute consists of a station identifier and a function identifier.

8.4.2.2.2 Function Invocation State

This attribute indicates the current state of the function invocation. An enumerated set of
values has been defined.

UNRUNNABLE This state indicates that the function invocation is not executing
and can not be executed.
IDLE This state indicates that the function invocation is not
executing, but is capable of being executed.
RUNNING This state indicates that the function invocation is executing.
STOPPED This state indicates that the execution of a function invocation
has been suspended.

8.4.3 Function Invocation ASE service specification

8.4.3.1 Supported services

This subclause contains the definition of services that are unique to this ASE. The services
defined for this ASE are:

• Start
• Stop
• Resume

Copyright International Electrotechnical Commission

8.4.3.2 Start service

8.4.3.2.1 Service overview

This confirmed service is used to start a function invocation from the initial condition.

8.4.3.2.2 Service primitives

The service parameters for each primitive are shown in Table 14.

Table 14 – Start service parameters

Parameter name Req Ind Rsp Cnf

Argument M =(M)
AREP M =(M)
InvokeID M =(M)
FunctionID M =(M)
Result M =(M)
AREP M =(M)
InvokeID M =(M)
Error Info M =(M)

FunctionID
This parameter specifies one of the key attributes of the function invocation object.

8.4.3.3 Stop service

8.4.3.3.1 Service overview

This confirmed service is used to stop a function invocation retaining its context so that it may
be resumed.

8.4.3.3.2 Service primitives

The service parameters for each primitive are shown in Table 15.

Table 15 – Stop service parameters

Parameter name Req Ind Rsp Cnf

Argument M =(M)
AREP M =(M)
InvokeID M =(M)
FunctionID M =(M)
Result M =(M)
AREP M =(M)
InvokeID M =(M)
Error Info M =(M)

FunctionID
This parameter specifies one of the key attributes of the function invocation object.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

8.4.3.4 Resume service

8.4.3.4.1 Service overview

This confirmed service is used to request to start a function invocation from the suspended
condition.

8.4.3.4.2 Service primitives

The service parameters for this service are shown in Table 16.

Table 16 – Resume service parameters

Parameter name Req Ind Rsp Cnf

Argument M =(M)
AREP M =(M)
InvokeID M =(M)
FunctionID M =(M)
Result M =(M)
AREP M =(M)
InvokeID M =(M)
Error Info M =(M)

FunctionID
This parameter specifies one of the key attributes of the function invocation object.

8.5 Time ASE

8.5.1 Overview

The Time ASE specifies the clock synchronization mechanism to synchronize the time among
network stations. This time can be used to add a time value to alert information and to
sequence messages in a time-wise order.

A system consists of one or more time master(s) and several time slaves. Clock
synchronization is performed by the communication system. Adjustment and management of
the clock are tasks of the application.

The network shall have at least one network time master which may be one of the domain
time masters selected automatically or may be a fixed station.

The network time master has the master clock of the network. The master clock may be the
local clock of the network time master itself or it may be synchronized with a clock source
outside the network.

The domain time master of each domain obtains network time from the network time master
and it distributes the network time value to stations in the domain.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

8.5.2 Time class specification

8.5.2.1 Formal model

FAL ASE: Time ASE
CLASS: Time
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Attribute: Implicit
2 (m) Attribute: Role
3 (o) Attribute: Stratum
4 (o) Attribute: Poll Interval
5 (o) Attribute: Precision
SERVICES:
1 (m) OpsService: Get Network Time
2 (m) OpsService: Set Network Time
3 (m) OpsService: Tick Notification service

8.5.2.2 Attributes

8.5.2.2.1 Role

This attribute specifies the role of the Time ASE with values defined as follows:
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

NETWORK TIME MASTER A network unique end node which responds to time
requests from domain masters.
DOMAIN TIME MASTER A domain unique end node which distributes time
information within the domain.
TIME SLAVE An end node subscribes time information distributed by the
domain master.
8.5.2.2.2 Stratum

This attribute indicates the stratum level of the local clock.

8.5.2.2.3 Poll Interval

This attribute indicates the maximum interval between successive time messages.

8.5.2.2.4 Precision

This attribute indicates the precision level of the local clock.

8.5.3 Time ASE service specification

8.5.3.1 Supported services

This subclause contains the definitions of services that are unique to this ASE. The services
defined for this ASE are:

• Get Network Time

• Set Network Time
• Tick Notification

8.5.3.2 Get Network Time service

8.5.3.2.1 Service overview

This local service shall be used to obtain the network time value that is distributed from the
network. If Time ASE is the network time master, the local time value of the master clock is
returned.

Copyright International Electrotechnical Commission

8.5.3.2.2 Service primitives

The service parameters for each primitive are shown in Table 17.

Table 17 – Get Network Time service parameters

Parameter name Req Cnf

Argument M
InvokeID M
Result M
InvokeID M
Network Time M
Status M
Error info C

Network Time
This parameter is the value of the network time.

Status
This parameter indicates the states of time synchronization. The possible states are;

• Not synchronized
• Synchronized to the domain time master
• Synchronized to the network time master as the domain time master
• Synchronized to an external time source as a network time master

8.5.3.3 Set Network Time service

8.5.3.3.1 Service overview

This confirmed service shall be used to set the value of network time to the time master.

This service is available under conditions where the network time master is not synchronized
to an external time source.

8.5.3.3.2 Service primitives

The service parameters for each primitive are shown in Table 18.

Table 18 – Set Network Time service parameters

Parameter name Req Ind Rsp Cnf

Argument M M(=)
InvokeID M M(=)
Network Time M M(=)
Result M M(=)
InvokeID M M(=)
Error Info C C(=)

Network Time
This parameter is the value of the network time to be set.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

8.5.3.4 Tick Notification service

8.5.3.4.1 Service overview

This local service shall be used to recognize tick timing synchronized to the network time. The
tick interval is configurable.

8.5.3.4.2 Service primitives

The service parameters for each primitive are shown in Table 19.

Table 19 – Set Network Time service parameters

Parameter name Ind

Result M
Tick M

Tick
This parameter indicates tick timing.
NOTE This service may be implemented by means of a hard-wired interruption.

8.6 Network Management ASE

8.6.1 Overview

End nodes may have two network interfaces that provide network redundancy. These
interfaces are referred to as network interface A and network interface B. The former shall be
connected to the primary network, while the latter shall be connected to the secondary
network.

Each Network Management ASE constructs two diagnostic message APDUs and sends them
concurrently to network interfaces A and B. Each Network Management ASE receives pairs of
APDUs from other end nodes on the network that participate in network redundancy. This
information is used to determine which network interface (A or B) is to be selected to send
other APDUs. This information is also used to determine whether the destination node is
reachable in advance of sending an APDU.

This information is preserved in the network status table.

8.6.2 Network Management class specification

8.6.2.1 Formal model

FAL ASE: Network Management
CLASS: Network Management
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Attribute: Number of Network Interfaces
2 (m) Attribute: Diagnostic Message Interval
3 (m) Attribute: Aging Time
4 (m) Attribute: List of Network Interface Status
SERVICES:
1 (m) OpsService: Get Network Status
2 (m) OpsService: Get Station Status
3 (m) OpsService: Network Status Change Report
4 (m) OpsService: Station Status Change Report

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

8.6.2.2 Attributes

8.6.2.2.1 Number of Network Interfaces

This attribute specifies the number of network interfaces on this end node. An end node may
have one or two network interfaces.

8.6.2.2.2 Diagnostic Message Interval

This attribute specifies the time interval between successive invocations of the diagnostic
messages in milliseconds.

8.6.2.2.3 Aging Time

This attribute specifies the time interval used to remove silent end nodes from the List of
Network Interface Status.

8.6.2.2.4 List of Network Interface Status

This attribute is a list of the path status representing the condition of the path to a remote
station from which the Network Management ASE may be receiving successive Diagnostic
Messages. The status is bi-directional for a path and indicates whether Diagnostic Messages
are being received successfully at each end of the path or whether either end of the path is in
a fault state.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
8.6.3 Network Management ASE service specification

8.6.3.1 Supported services

This subclause contains the definition of the services that is unique to this ASE.

The services defined for this ASE are:

• Get Network Status

• Get Station Status
• Network Status Change Report
• Station Status Change Report

8.6.3.2 Get Network Status service

8.6.3.2.1 Service overview

This local service is used to obtain the status of the network.

8.6.3.2.2 Service primitives

The service parameters for each primitive are shown in Table 20.

Table 20 – Get Network Status service parameters

Parameter name Req Cnf

Argument M
InvokeID M
Result M
InvokeID M
Network Status M

Copyright International Electrotechnical Commission

Network Status
This parameter indicates consistency of the primary and secondary networks. Possible values
are:

• HEALTHY
• FAILED

8.6.3.3 Get Station Status service

8.6.3.3.1 Service overview

This local service is used to obtain the status of the specified station.

8.6.3.3.2 Service primitives

The service parameters for each primitive are shown in Table 21.

Table 21 – Get Station Status service parameters

Parameter name Req Cnf

Argument M
Station Identifier M

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
InvokeID M
Result M
InvokeID M
Station Status M
Route Status M

Station Identifier
This parameter indicates the station for which the status is requested, and consists of a
domain number and a station number.

Station Status
This parameter indicates the status of the station specified by the station identifier, and
includes the following information.

a) existence
TRUE the station exists
FALSE the station does not exist
b) redundancy
SINGLE the station is not redundant
DUAL-REDUNDANT the station is redundant
c) AREP of the end node which is on service
Route Status
This parameter indicates the status of route for the station, and includes the following
information.

a) status of the route on the primary network

REACHABLE
UNREACHABLE
b) status of the route on the secondary network
REACHABLE
UNREACHABLE

Copyright International Electrotechnical Commission

8.6.3.4 Network Status Change Report service

8.6.3.4.1 Service overview

This local service is used to inform of changes in network status.

8.6.3.4.2 Service primitives

The service parameters for each primitive are shown in Table 22.

Table 22 – Network Status Change Report service parameters

Parameter name Ind

Result M
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Network Status M

Network Status
This parameter indicates consistency of the primary and secondary networks, and has the
following possible values:

• HEALTHY
• FAILED

8.6.3.5 Station Status Change Report service

8.6.3.5.1 Service overview

This local service is used to inform of changes in the station status.

8.6.3.5.2 Service primitives

The service parameters for each primitive are shown in Table 23.

Table 23 – Station Status Change Report service parameters

Parameter name Ind

Result M
Station Identifier M
Station Status M
Route Status M

Station Identifier
This parameter indicates the station of which the status has changed.

Station Status
This parameter indicates the status of the end node specified in/by the request primitive and
includes the following information:

Copyright International Electrotechnical Commission

Route Status
This parameter indicates the status of the route for the station, and includes the following
information:

a) status of the route on the primary network

REACHABLE
UNREACHABLE
b) status of the route on the secondary network
REACHABLE
UNREACHABLE

8.7 Application Relationship ASE

8.7.1 Overview

8.7.1.1 General

In a distributed system, application processes communicate with each other by exchanging

Application Layer messages across well-defined Application Layer communication channels.

These communication channels are modeled in the Fieldbus Application Layer as application
relationships (ARs).

ARs are responsible for conveying messages between applications according to specific
communication characteristics required by time-critical systems. Different combinations of
these characteristics lead to the definitions of different types of ARs. The characteristics of
ARs are defined formally as attributes of AR endpoint classes.

The messages that are conveyed by ARs are FAL service requests and responses. Each is
submitted to the AR ASE for transfer by an FAL Application Service Element (ASE) that
represents the class of the APO being accessed. Figure 2 illustrates this concept.

Depending on the type of AR, APDUs may be sent to one or more destination application
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

processes connected by the AR. Other characteristics of the AR determine how APDUs are to
be transferred. These characteristics are described below.

Copyright International Electrotechnical Commission

PAS 62405 © IEC:2005(E) – 45 –

FAL AP

APO Service Primitives

FAL AE

FAL APO ASE

AR Confirmed AR Unconfirmed
Send Service Send Service
Primitives Primitives

AR ASE

Conveyance of APDUs
By the AR ASE

Figure 2 – The AR ASE conveys APDUs between APs

8.7.1.2 Endpoint context

Each AP involved in an AR contains an endpoint of the AR. Each AR endpoint is defined

within the AE of the AP. An endpoint definition, when combined with the definitions of the
other endpoints, defines an AR. To ensure communication compatibility among or between
endpoints, each endpoint definition contains a set of compatibility-related characteristics.

These characteristics need to be configured appropriately for each endpoint for the AR to
operate properly.

Endpoint definitions also contain a set of characteristics that describe the operation of the AR.
These characteristics, when combined with those used to specify compatibility, define the
context of the endpoint. The endpoint context is used by the AR ASE to manage the operation
of the endpoint and the conveyance of APDUs. The characteristics that comprise the endpoint
context are described in the next section.

8.7.1.2.1 Endpoint role

The role of an AREP determines the permissible behaviour of an AP at the AREP. An AREP
role may be that of a client, server, peer (client and/or server), publisher or subscriber.

Table 24 and Table 25 summarize the characteristics and combinations of each of the AREP
roles.

Table 24 – Conveyance of service primitives by AREP role

Client Server Peer Publisher Subscriber

Send Service Req X X X

Recv Service Req X X X
Send Service Rsp X X
Recv Service Rsp X X

Copyright International Electrotechnical Commission

Table 25 – Valid combinations of AREP roles involved in an AR

Client Server Peer Publisher Subscriber

Client X X
Server X X
Peer X X X
Publisher X
Subscriber X

8.7.1.2.2 Dedicated AR endpoints

Dedicated AR endpoints provide their services directly to the FAL User. Although their
behaviour is the same as that of non-dedicated endpoints, the APDUs they convey contain no
service specific protocol control information other than the AR control field.

FAL Users configured for dedicated ARs construct and transfer their data without using the
services of the other FAL ASEs. The format and contents of the user data conveyed over
dedicated ARs are known only through configuration.

8.7.1.2.3 Cardinality

The cardinality of an AR specifies, from the point of view of a client or publisher endpoint, how
many remote application processes are involved in an AR. Cardinality is never expressed
from the viewpoint of a server or a subscriber.

When expressed from the viewpoint of a client or peer endpoint, ARs are always one-to-one.
Clients are never capable of issuing a request to multiple servers and waiting for responses
from them.

When expressed from the viewpoint of a publisher endpoint, the cardinality indicates that
multiple subscribers are supported. These one-to-many ARs provide communications between
one application and a group of (one or more) applications. They are often referred to as multi-
party and multicast.

In one-to-many ARs, the publisher endpoint identifies the remote endpoints using a group
identifier, rather than identifying each one individually as is done with one-to-one ARs. This
permits subscribers to join and leave ARs without disrupting the publisher endpoint context
because their individual identities are not known to the publisher endpoint. However, the
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

publisher application may be aware of their participation, but that information is not part of the
AR endpoint context.

8.7.1.2.4 Conveyance model

The conveyance model defines how APDUs are sent between endpoints of an AR. Three
characteristics are used to define these transfers:

• conveyance paths,
• trigger policy, and
• conveyance policy.
Conveyance paths
The purpose of AR ASEs is to transfer information between AR endpoints. This information
transfer occurs over the conveyance paths of an AR. A conveyance path represents a one-
way communication path used by an endpoint for input or output.

Copyright International Electrotechnical Commission

To support the role of the application process, the endpoint is configured with either one or
two conveyance paths. Endpoints that only send or only receive are configured with either a
send or receive conveyance path, respectively, and those that do both are configured with
both. ARs with a single conveyance path are called unidirectional, and those with two
conveyance paths are called bi-directional.

Unidirectional ARs are capable of conveying service requests only. To convey service
responses, a bi-directional AR is necessary. Therefore, unidirectional ARs support the
transfer of unconfirmed services in one direction only, while bi-directional ARs support the
transfer of unconfirmed and confirmed services initiated by only one endpoint, or by both
endpoints.

Trigger policy
Trigger policy indicates when APDUs are transmitted over the network by the Data Link Layer.

The first type is referred to as user-triggered. User-triggered AREPs submit FAL APDUs to the
Data Link Layer for transmission at the earliest opportunity.

The second type is referred to as network-scheduled. Network scheduled AREPs submit FAL
APDUs to the Data Link Layer for transmission according to a schedule configured by
management.

Conveyance policy
Conveyance policy indicates whether APDUs are transferred according to a buffer model or a
queue model. These models describe the method of conveying APDUs from the sender to the
receiver.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Buffered ARs contain conveyance paths that have a single buffer at each endpoint. Updates
to the source buffer are conveyed to the destination buffer according to the trigger policy of
the AR. Updates to either buffer replace its contents with new data. In buffered ARs,
unconveyed or undelivered data that have been replaced are lost. In additional data contained
in a buffer may be read multiple times without destroying its contents.

Queued ARs contain conveyance paths that are represented as a queue between endpoints.
Queued ARs convey data using a FIFO queue. Queued ARs are not overwritten, meaning that
new entries are queued until they can be conveyed and delivered.

If a queue is full, a new message will not be placed into the queue.

8.7.1.3 AR establishment

For an AR endpoint to be used by an application process, the corresponding AR shall be

active. When an AR is activated, it is referred to as “established”.

AR establishment can occur in one of three ways.

First, ARs can be pre-established, meaning that the AE that maintains the endpoint context is
created when the AP is connected to the network. In this case, communications among the
applications involved in the AR may take place without first having to explicitly establish the
AR. Any AR may be defined as being pre-established.

Second, ARs can be pre-defined, but not pre-established. Pre-defined means that the
characteristics of the AR are known to each endpoint, but that their contexts have not been
synchronized for operation. In this case, the use of the FAL Establish service is required to
synchronize them and open them for data transfer.

Third, ARs can require dynamic definition and establishment. In this case, definitions shall be
created for each of the AREPs using the Create service. After creation, they are established
using the Establish service if they were not created as “established”.

Copyright International Electrotechnical Commission

8.7.2 Application Relationship Class specification

8.7.2.1 Formal model

The AR endpoint formal model defines the characteristics common to all AR endpoints. This
class is not capable of being instantiated. It is present only for the inheritance of its attributes
and services by its subclasses, each specified in a separate subclause of this PAS.

All AR endpoint attributes are accessible through system Management.

FAL ASE: AR ASE

CLASS: AR ENDPOINT
CLASS ID: not used
PARENT CLASS: TOP
ATTRIBUTES:
1 (m) Attribute: FAL Revision
2 (m) Attribute: Dedicated (TRUE, FALSE)
3 (m) Attribute: Cardinality (one-to-one, one-to-many)
4 (m) Attribute: Conveyance policy (Queued, Buffered)
5 (m) Attribute: Conveyance path (Unidirectional, Bi-directional)
6 (m) Attribute: Trigger policy (User-triggered , Network-scheduled)
7 (o) Attribute: Transfer Syntax
SERVICES:
1 (o) OpsService: AR-Unconfirmed Send
2 (o) OpsService: AR-Confirmed Send
3 (o) OpsService: AR-Establish
4 (o) OpsService: AR-Abort

8.7.2.2 Attributes
FAL Revision
This specifies the revision level of the FAL protocol used by this endpoint. The revision level
is in the AR header of all FAL-PDUs transmitted.

Dedicated
This attribute specifies whether the endpoint is dedicated or not. When TRUE, the services of
the AR ASE are accessed directly by the FAL User.

Cardinality
This attribute specifies cardinality of the AR described in subclause 2.7.1.

Conveyance policy
This attribute specifies conveyance policy of the AR described in subclause 2.7.1.

Conveyance path
This attribute specifies conveyance path of the AR described in subclause 2.7.1.

Trigger policy
This attribute specifies trigger policy of the AR described in subclause 2.7.1.

Transfer Syntax
This optional attribute identifies the encoding rules to be used on the AR. When not present,
the default FAL Transfer Syntax of this standard is used.

8.7.2.3 Services
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

All services defined for this class are optional. When an instance of the class is defined, at
least one shall be selected.

AR-Unconfirmed Send
This optional service is used to send an unconfirmed service.

AR-Confirmed Send
This optional service is used to send a confirmed service.

Copyright International Electrotechnical Commission

AR-Establish
This optional service is used to establish (open) an AR.

AR-Abort
This optional service is used to abort (abruptly terminate) an AR.

8.7.3 Application Relationship ASE service specification

8.7.3.1 Supported services

This subclause contains the definitions of services that are unique to this ASE. The services
defined for this ASE are:

• AR-Unconfirmed Send
• AR-Confirmed Send
• AR-Establish
• AR-Abort

The services AR-Confirmed Send contain the FAL PDU body as part of the Result parameter
in the response and confirmation primitives. The FAL PDU body may contain either the
positive response or negative response returned by the FAL User transparently to the AR ASE.
Therefore, these services have a single Result parameter instead of the separate Result(+)
and Result(-) parameters that are commonly used to convey the positive and negative
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

responses returned by the FAL User.

8.7.3.2 AR-Unconfirmed Send service

8.7.3.2.1 Service overview

This service is used to send AR-Unconfirmed Send request APDUs for FAL APO ASEs. The
AR-Unconfirmed Send service may be requested at either endpoint of a one-to-one bi-
directional AR, at the server endpoint of a one-to-one unidirectional AR, or at the publisher
endpoint of a one-to-many AR.

8.7.3.2.2 Service primitives

The service parameters for each primitive are shown in Table 26.

Table 26 – AR-Unconfirmed Send

Parameter name Req Ind

Argument M M(=)
AREP M M(=)
Remote DL Address M M(=)
FAL Service Type M M(=)
FAL APDU Body M M(=)

Remote DL Address
This parameter contains the destination DLSAP address in the request and the source DLSAP
address in the indication.

FAL Service Type

This parameter contains the type of service being conveyed.

FAL APDU Body

This parameter contains the service-dependent body for the APDU.

Copyright International Electrotechnical Commission

8.7.3.2.3 Service procedure

The AR-Unconfirmed Send service is a service that operates through a queue.

The requesting FAL ASE submits an AR-Unconfirmed Send request primitive to its AR ASE.
The AR ASE builds an AR-Unconfirmed Send request APDU.

The AR ASE queues the APDU for submission to the lower layer.

If the AREP is user-triggered, the AR ASE immediately requests the lower layer to transfer the
APDU. If the AR is network-scheduled, the AR ASE requests the DL to transfer the data at the
scheduled time. The Data Link mapping indicates how the AR ASE coordinates its requests to
transmit the data with the Data Link Layer.

Upon receipt of the AR-Unconfirmed Send request APDU, the receiving AR ASE delivers an
AR-Unconfirmed Send indication primitive to the appropriate FAL ASE as indicated by the
FAL Service Type Parameter.

8.7.3.3 AR-Confirmed Send service

8.7.3.3.1 Service overview

This service is used to send confirmed request and response APDUs for FAL APO ASEs. The
AR-Confirmed Send service may be requested at Client and Peer endpoints of one-to-one bi-
directional ARs.

8.7.3.3.2 Service primitives

The service parameters for each primitive are shown in Table 27.

Table 27 – AR-Confirmed Send

Parameter name Req Ind Rsp Cnf

Argument M M(=)
AREP M M(=)
InvokeID M M(=)
Server DL-Address M M(=)
FAL Service Type M M(=)
FAL APDU Body M M(=)
Result M M(=)
AREP M M(=)
InvokeID M M(=)
Client DL-Address M M(=)
FAL Service Type M M(=)
FAL APDU Body M M(=)

Server DL-Address
This parameter contains the DL-address of the server.

FAL Service Type

This parameter contains the type of service being conveyed.

FAL APDU Body

This parameter contains the service-dependent body for the APDU.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Result
This parameter indicates that the service request succeeded or failed.

Client DL-Address
This parameter contains the DL-address of the client.

8.7.3.3.3 Service procedure

The AR-Confirmed Send service is a service that operates through a queue.

The requesting FAL ASE submits an AR-Confirmed Send request primitive to its AR ASE. The
AR ASE creates a transaction state machine to control the invocation of the service.

The AR ASE builds an AR-Confirmed Send request APDU and queues the APDU for
submission to the lower layer, then the AR ASE immediately requests the lower layer to
transfer the APDU.

Upon receipt of the AR-Confirmed Send request APDU, the receiving AR ASE delivers an AR-
Confirmed Send indication primitive to the appropriate FAL ASE as indicated by the FAL
Service Type Parameter.

The responding FAL ASE submits a confirmed send response primitive to its AR ASE. The AR
ASE builds a confirmed send response APDU.

The AR ASE queues the APDU for submission to the lower layer. In addition, the AR ASE
immediately requests the lower layer to transfer the APDU.

Upon receipt of the confirmed send response APDU, the receiving AR ASE uses the InvokeID
contained in the response APDU to associate the response with the appropriate request and
cancel the associated transaction state machine. The AR ASE delivers an AR-Confirmed
Send confirmation primitive to the requesting FAL ASE.

If the timer expires before the sending AR ASE receives the response APDU, the AR ASE
cancels the associated transaction state machine and delivers an AR-Confirmed Send
confirmation(-) primitive to the requesting FAL ASE.

8.7.3.4 AR-Establish service

8.7.3.4.1 Service overview

This confirmed service operates in a pair-wise manner between two AR endpoints to

synchronize their contexts and activate them for the transfer of APDUs.

The endpoint context may be created during or prior to establishment through System
Management. Once defined, the Set Attributes and Get Attributes services can be used to
update and further coordinate endpoint contexts.

8.7.3.4.2 Service primitives

The service parameters for each primitive are shown in Table 28

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 28 – AR-Establish service

Parameter name Req Cnf

Argument M
AREP M
Remote DL-Address M
Result M(=)
AREP M(=)
Error Info C

AREP
This parameter contains sufficient information to locally identify the AREP to be established.

Remote DL-address
This parameter identifies the remote DL-address.

Result
This parameter indicates whether the service request succeeded or failed.

8.7.3.4.3 Service procedure

8.7.3.4.3.1 AR establishment

The AR-Establish service causes local AREPs to be established independently.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Upon receipt of an AR-Establish request service primitive, the calling FAL issues an AR-
Establish confirmation service primitive to the calling AP indicating whether or not it was able
to establish the AREP. If one of the following cases is found, it was not able to establish the
AREP:

a) the requested AREP is not specified within the FAL, or

b) resources are not available to establish the requested AREP, or
c) for AREPs supported by a data link connection, the Data Link Layer was not able to
establish the data link connection.

8.7.3.5 AR-Abort service

8.7.3.5.1 Service overview

The service is used by the FAL User to terminate an AR abruptly. It is always successful; the
receiver of an Abort request always aborts the AR. This service may be used on any open
AREP, regardless of whether the AR was pre-established or established dynamically using
the establish service.

The AR-Abort service is used to instruct the AR ASE to abruptly terminate all activity on an
AREP and place it in the closed state. Receipt of an AR-Abort request primitive causes the
AR ASE to close the AREP context immediately. The immediate close of each endpoint
context causes all outstanding service requests to be cleared. All subsequent service
primitives and APDUs received by the AR ASE for the aborted AR are discarded except those
of the AR-Establish service.

The AR ASE may also initiate the Abort service if it detects unrecoverable communication
failures. In this case, the AR ASE delivers an AR-Abort indication primitive informing the user
of the failure and closes the endpoint context.

Copyright International Electrotechnical Commission

8.7.3.5.2 Service primitives

The service parameters for each primitive are shown in Table 29.

Table 29 – AR-Abort

Parameter name Req Ind

Argument M M(=)
AREP M M(=)
Originator M M(=)
Reason Code M M(=)
Additional Detail U U(=)

Originator
This parameter identifies the originator of the AR-Abort. Possible values are “DLL”, “FAL”, or
“FAL-USER”. The value DLL cannot be used in the request primitive.

Reason Code
This parameter indicates the reason for the Abort. It may be supplied by either the provider or
the user. One reason is defined: AR ASE error. Other reason code values may be supplied by
the Data Link Layer or by the user.

Additional Detail
This optional parameter contains user data that accompanies the indication. When used, the
value submitted in the request primitive is delivered unchanged in the indication primitive.

8.7.3.5.3 Service procedure

The Abort service is a service that operates through a queue.

If the user wishes to abort an AR, it submits an Abort request primitive to its FAL AR ASE. If
an AR ASE detects an unrecoverable local failure or a communication failure, it delivers an
abort indication primitive to the endpoint user.

The FAL AR ASE also transitions the AREP state to CLOSED.

9 ARs

9.1 General

Application Relationships provided are:

• Point-to-point user-Triggered Confirmed client/server AREP (PTC-AR)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

• Point-to-point user-Triggered Unconfirmed client/server AREP (PTU-AR)

• Point-to-point network-Scheduled Unconfirmed publisher/subscriber AREP (PSU-AR)
• Multipoint user-Triggered Unconfirmed publisher/subscriber AREP (MTU-AR)
• Multipoint network-Scheduled Unconfirmed publisher/subscriber AREP (MSU-AR)

9.2 Point-to-point user-Triggered Confirmed client/server AREP (PTC-AR)

9.2.1 Overview

This class is defined to support the on-demand exchange of confirmed services between two
application processes. Unconfirmed services are not supported by this type of AR. It uses
connectionless-mode Data Link Services for the exchanges. The Data Link Layer transfers
may be either acknowledged or unacknowledged. The behaviour of this class is described as

Copyright International Electrotechnical Commission

follows. An AR ASE user wishing to convey a request APDU submits it as an AR ASE Service
Data Unit to its AREP and the AREP sending the request APDU queues it to its underlying
layer for transfer at the next available opportunity.

The AREP receiving the request APDU from its underlying layer queues it for delivery to its
AR ASE user in the order in which it was received.

The AREP receiving the request APDU accepts the corresponding response APDU from its
AR ASE user and queues it to the underlying layer for transfer.

The AREP that issued the request APDU receives the response APDU from its underlying
layer and queues it for delivery to its AR ASE user in the order in which it was received. It
also stops its associated service response timer.

The characteristics of this AREP class are summarized as follows:

Roles Client
Server
Peer
Cardinality one-to-one
Conveyance paths Bi-directional
Trigger policy User-triggered
Conveyance policy Queued

9.2.2 Formal model

FAL ASE: AR ASE
CLASS: PTC-AR
CLASS ID: not used
PARENT CLASS: AR ENDPOINT
ATTRIBUTES:
1 (m) Attribute: Role (CLIENT, SERVER, PEER)
2 (m) Attribute: AREP State
3 (m) Attribute: Maximum Outstanding Requests Calling
4 (m) Attribute: Maximum Outstanding Requests Called
5 (m) Attribute: Transmit DL Mapping Reference
6 (m) Attribute: Receive DL Mapping Reference
SERVICES:
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
1 (m) OpsService: Confirmed Send

9.2.3 Attributes
Role
This attribute specifies the role of the AREP. Possible values are:

PEER (CLIENT/SERVER) Endpoints of this type may perform as either clients or

servers, or as both simultaneously.
CLIENT Endpoints of this type issue confirmed service Request-
APDUs to servers and receive confirmed service Response-
APDUs.
SERVER Endpoints of this type receive confirmed service Request-
APDUs from clients and issue confirmed service Response-
APDUs to them.

AREP State
This attribute specifies the state of the AREP. The values for this attribute are specified in
part 3 of this document.

Copyright International Electrotechnical Commission

Max Outstanding Requests Calling

This conditional attribute indicates the maximum number of responses that the AREP may be
expecting from the remote AREP.

Max Outstanding Requests Called

This conditional attribute indicates the maximum number of responses that the AR endpoint
may be expecting from its local user.

Transmit DL Mapping Reference

This attribute provides a reference to the underlying Data Link Layer mapping for the transmit
conveyance path for this AREP. DL mappings for the Data Link Layer are specified in part 3
of this document.

Receive DL Mapping Reference

This attribute provides a reference to the underlying Data Link Layer mapping for the receive
conveyance path for this AREP. DL mappings for the Data Link Layer are specified in part 3
of this document.

9.2.4 Services
Confirmed Send
This optional service is used to send a confirmed service on an AR.

9.3 Point-to-point user-Triggered Unconfirmed client/server AREP (PTU-AR)

9.3.1 Overview

This class is defined to support the on-demand exchange of unconfirmed services between
two application processes. It uses connectionless-mode Data Link Services for the exchanges.
The Data Link Layer transfers may be either acknowledged or unacknowledged. The
behaviour of this class is described as follows.

An AR ASE user wishing to convey a request APDU submits it as an AR ASE Service Data
Unit to its AREP. The AREP sending the request APDU queues it to its underlying layer for
transfer at the next available opportunity.

The AREP receiving the request APDU from its underlying layer queues it for delivery to its
AR ASE user in the order in which it was received.

The characteristics of this AREP class are summarized as follows:

Roles Client
Server
Peer
Cardinality one-to-one
Conveyance paths Unidirectional
Trigger policy User-triggered
Conveyance policy Queued

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

9.3.2 Formal model

FAL ASE: AR ASE
CLASS: Point-to-point user-Triggered Unconfirmed client/server AREP
CLASS ID: not used
PARENT CLASS: AR ENDPOINT
ATTRIBUTES:
1 (m) Attribute: Role (CLIENT, SERVER, PEER)
2 (m) Attribute: AREP State
3 (m) Attribute: Transmit DL Mapping Reference
4 (m) Attribute: Receive DL Mapping Reference
SERVICES:
1 (m) OpsService: Unconfirmed Send

9.3.3 Attributes
Role
This attribute specifies the role of the AREP. Possible values are:

PEER (CLIENT/SERVER) Endpoints of this type may perform as either clients or

servers, or as both simultaneously. Endpoints of this type
shall indicate whether they are to be the initiator of the AR
establishment process.
CLIENT Endpoints of this type issue unconfirmed service Request-
APDUs to servers.
SERVER Endpoints of this type receive confirmed and unconfirmed
service Request-APDUs from clients.
AREP State
This attribute specifies the state of the AREP. The values for this attribute are specified in
Section 3 of this PAS.

Transmit DL Mapping Reference

This attribute provides a reference to the underlying Data Link Layer mapping for the transmit
conveyance path for this AREP. DL mappings for the Data Link Layer are specified in
Section 3 of this PAS.

Receive DL Mapping Reference

This attribute provides a reference to the underlying Data Link Layer mapping for the receive
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

conveyance path for this AREP. DL mappings for the Data Link Layer are specified in
Section 3 of this PAS.

9.3.4 Services
Unconfirmed Send
This optional service is used to send an unconfirmed service on an AR.

9.4 Point-to-point network-Scheduled Unconfirmed publisher/subscriber AREP (PSU-

AR)

9.4.1 Overview

This class is defined to support the “push” model for scheduled and buffered distribution of
unconfirmed services to one application process.

The behaviour of this type of AR can be described as follows.

An AR ASE user wishing to convey a request APDU submits it as an AR ASE Service Data
Unit to its AREP for distribution. Sending AREP writes the APDU into the internal buffer,
completely replacing the existing contents of the buffer. The AR ASE transfers the buffer
contents at the next scheduled transfer opportunity.

Copyright International Electrotechnical Commission

If the AREP receives another APDU before the buffer contents are transmitted, the buffer
contents will be replaced with the new APDU, and the previous APDU will be lost. When the
buffer contents are transmitted, the AR ASE notifies the user of transmission.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

At the receiving endpoint, the APDU is received from the network and is written immediately
into the buffer, completely overwriting the existing contents of the buffer. The endpoint notifies
the user that the APDU has arrived and delivers it to the user according to the local user
interface. If the APDU has not been delivered before the next APDU arrives, it will be
overwritten by the next APDU and lost.

An FAL user receiving the buffered transmission may request to receive the currently buffered
APDU later.

The characteristics of this AREP class are summarized as follows:

Roles Publisher
Subscriber
Cardinality one-to-one
Conveyance paths Unidirectional
Trigger policy Network-scheduled
Conveyance policy Buffered

9.4.2 Formal model

FAL ASE: AR ASE
CLASS: Point-to-point network-Scheduled Unconfirmed
publisher/subscriber AREP
CLASS ID: not used
PARENT CLASS: AR ENDPOINT
ATTRIBUTES:
1 (m) Attribute: Role (PUBLISHER, SUBSCRIBER)
2 (m) Attribute: AREP State
3 (m) Attribute: Transmit DL Mapping Reference
4 (m) Attribute: Receive DL Mapping Reference
SERVICES:
1 (o) OpsService: Unconfirmed Send

9.4.3 Attributes
Role
This attribute specifies the role of the AREP. Possible values are:

PUBLISHER Endpoints of this type issue unconfirmed service Request-APDUs to

subscribers.
SUBSCRIBER Endpoints of this type receive unconfirmed service Request-APDUs
issued by the publisher.
AREP State
This attribute specifies the state of the AREP. The values for this attribute are specified in
Section 3 of this PAS.

Transmit DL Mapping Reference

Receive DL Mapping Reference

This attribute provides a reference to the underlying Data Link Layer mapping for the receive
conveyance path for this AREP. DL mappings for the Data Link Layer are specified in
Section 3 of this PASt.

Copyright International Electrotechnical Commission

9.4.4 Services
Unconfirmed Send
This optional service is used to send an unconfirmed service on an AR.

9.5 Multipoint user-Triggered Unconfirmed publisher/subscriber AREP (MTU-AR)

9.5.1 Overview

This class is defined to support the on-demand exchange of unconfirmed services between
two or more application processes. This class uses connectionless Data Link Services for the
exchanges. The behaviour of this class is as follows.

The AREP receiving the request APDU from its underlying layer queues it for delivery to its
AR ASE user in the order in which it was received.

The characteristics of this AREP class are summarized as follows:

Roles Publisher
Subscriber
Cardinality one-to-many
Conveyance paths Unidirectional
Trigger policy User-triggered
Conveyance policy Queued

9.5.2 Formal model

FAL ASE: AR ASE
CLASS: Multipoint user-Triggered Unconfirmed publisher/subscriber
AREP
CLASS ID: not used
PARENT CLASS: AR ENDPOINT
ATTRIBUTES:
1 (m) Attribute: Role (PUBLISHER, SUBSCRIBER)
2 (m) Attribute: AREP State
3 (m) Attribute: Transmit DL Mapping Reference
4 (m) Attribute: Receive DL Mapping Reference
SERVICES:
1 (m) OpsService: Unconfirmed Send

9.5.3 Attributes
Role
This attribute specifies the role of the AREP. Possible values are:

PUBLISHER Endpoints of this type issue unconfirmed service Request-APDUs to

subscribers.
SUBSCRIBER Endpoints of this type receive unconfirmed service Request-APDUs
issued by the publisher.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

AREP State
This attribute specifies the state of the AREP. The values for this attribute are specified in
Section 3 of this PAS.

Transmit DL Mapping Reference

Receive DL Mapping Reference

9.5.4 Services
Unconfirmed Send
This optional service is used to send an unconfirmed service on an AR.

9.6 Multipoint network-Scheduled Unconfirmed publisher/subscriber AREP (MSU-AR)

9.6.1 Overview

This class is defined to support the “push” model for scheduled and buffered distribution of
unconfirmed services to one or more application processes.

The behaviour of this type of AR can be described as follows.

An AR ASE user wishing to convey a request APDU submits it as an AR ASE Service Data
Unit to its AREP for distribution. The sending AREP writes the APDU into the internal buffer,
completely replacing the existing contents of the buffer.

The AREP transfers the buffer contents at the next scheduled transfer opportunity.

An FAL user receiving the buffered transmission may request to receive the currently
buffered APDU later.

The characteristics of this AREP class are summarized as follows:

Roles Publisher
Subscriber
Cardinality one-to-many
Conveyance paths Unidirectional
Trigger policy Network-scheduled
Conveyance policy Buffered

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

9.6.2 Formal model

FAL ASE: AR ASE
CLASS: Multipoint network-Scheduled Unconfirmed
publisher/subscriber AREP
CLASS ID: not used
PARENT CLASS: AR ENDPOINT
ATTRIBUTES:
1 (m) Attribute: Role (PUBLISHER, SUBSCRIBER)
2 (m) Attribute: AREP State
3 (m) Attribute: Transmit DL Mapping Reference
4 (m) Attribute: Receive DL Mapping Reference
SERVICES:
1 (o) OpsService: Unconfirmed Send

9.6.3 Attributes
Role
This attribute specifies the role of the AREP. Possible values are:

PUBLISHER Endpoints of this type publish their data issuing unconfirmed service
Request-APDUs.
SUBSCRIBER Endpoints of this type receive unconfirmed service Request-APDUs
issued by publishers.
AREP State
This attribute specifies the state of the AREP. The values for this attribute are specified in
Section 3 of this PAS.

Transmit DL Mapping Reference

Receive DL Mapping Reference

9.6.4 Services
Unconfirmed Send
This optional service is used to send an unconfirmed service on an AR.

10 Summary of FAL classes

This subclause contains a summary of the defined FAL Classes. The Class ID values have
been assigned to be compatible with existing standards.

Table 30 provides a summary of the classes.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 30 – FAL class summary

FAL ASE Class

Variable Variable
Variable List
Event Notifier
Load region Load region
Function invocation Function invocation
Time Time
Network Management Network Manager
Application relationship AREP
PTC-AREP
PTU-AREP
PSU-AREP
MTU-AREP
MSU-AREP

11 Permitted FAL services by AREP role

Table 31 below defines the valid combinations of services and AR types (which service APDUs
can be sent or received by AR with the specified type). “Unc” and “Cnf” columns indicate whether
the service listed in the left-hand column is unconfirmed or confirmed respectively.

Table 31 – FAL services by AR type

Unc Cnf Client Server Publisher Subscriber

FAL Services r eq rcv r eq rcv r eq rcv r eq rcv
Variable ASE
Read X X X
Write X X X
Information Report X X X X
Event ASE
Event Notification X X X
Notification Recovery X X X
Load Region ASE
Download X X X
Upload X X X
Function invocation ASE
Start X X X
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Stop X X X
Resume X X X
Time ASE
Get Network Time X
Set Network Time X X X
Tick Notification service X X X
NW Management ASE
Get Network Status X
Get Station Status X
NW Status Report X X X
Station Status Report X X X
AR ASE
PTC-AR X X X
PTU-AR X X X
PSU-AR X X X
MTU-AR X X X
MSU-AR X X X

Copyright International Electrotechnical Commission

Section 3: Application Layer protocol specification

12 Abstract syntax

12.1 FAL PDU abstract syntax

12.1.1 Top level definition

FalArPDU ::=
ConfirmedSend-CommandPDU
|| ConfirmedSend-ResponsePDU
|| UnconfirmedSend-CommandPDU

12.1.2 FalArHeader

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
FalArHeader ::= Unsigned8{
-- bit 8-7 ProtocolVersion
-- bit 6-4 ProtocolIdentifier
-- bit 3-1 PDUIdentifier
}

12.1.3 Confirmed send service

ConfirmedSend-CommandPDU ::= SEQUENCE {
FalArHeader,
ServiceType
InvokeID,
ConfirmedServiceRequest
}

ConfirmedSend-ResponsePDU ::= SEQUENCE {

FalArHeader,
ServiceType
InvokeID,
ConfirmedServiceResponse
}

12.1.4 Unconfirmed send service

UnconfirmedSend-CommandPDU ::= SEQUENCE {
FalArHeader,
ServiceType
InvokeID,
UnconfirmedServiceRequest
}

12.2 Abstract syntax of PDU Body

12.2.1 ConfirmedServiceRequest PDUs

ConfirmedServiceRequest ::= CHOICE {
Read-Request [0] IMPLICIT Read-RequestPDU,
Write-Request [1] IMPLICIT Write-RequestPDU,
DownLoad-Request [2] IMPLICIT DownLoad-RequestPDU,
UpLoad-Request [3] IMPLICIT UpLoad-RequestPDU,
Start-Request [4] IMPLICIT Start-RequestPDU,
Stop-Request [5] IMPLICIT Stop-RequestPDU,
Resume- Request [6] IMPLICIT Resume-RequestPDU,
DelayCheck-Request [7] IMPLICIT Time- RequestPDU,
}

Copyright International Electrotechnical Commission

12.2.2 ConfirmedServiceResponse PDUs

ConfirmedServiceResponse ::= CHOICE {
Read-Response [0] IMPLICIT Read-ResponsePDU,
Write-Response [1] IMPLICIT Write-ResponsePDU,
DownLoad-Response [2] IMPLICIT DownLoad-ResponsePDU,
UpLoad-Response [3] IMPLICIT UpLoad-ResponsePDU,
Start-Response [4] IMPLICIT Start-ResponsePDU,
Stop-Response [5] IMPLICIT Stop-ResponsePDU,
Resume-Response [6] IMPLICIT Resume-ResponsePDU,
DelayCheck-Response [7] IMPLICIT Time-ResponsePDU
}

12.2.3 Unconfirmed PDUs

UnconfirmedServiceRequest ::= CHOICE {
InformationReport-Request [0] IMPLICIT InformationReport-RequestPDU,
EventNotification-Request [1] IMPLICIT EventNotification-RequestPDU,
EventRecovery-Request [2] IMPLICIT EventRecovery-RequestPDU,
TimeDistribution-Request [3] IMPLICIT TimeDistribute-RequestPDU,
SetTime-Request [4] IMPLICIT SetTime-RequestPDU,
InDiag-Request [5] IMPLICIT InDiag-RequestPDU,
ExDiag-Request [6] IMPLICIT ExDiag-RequestPDU,
StationStatusReport-Request [7] IMPLICIT StationStatusReport-RequestPDU,
DomainStatusReport-Request [8] IMPLICIT DomainStatusReport-RequestPDU
}

12.2.4 Error information

12.2.4.1 Error type

ErrorType ::= SEQUENCE {
errorClass [0] IMPLICIT ErrorClass,
additionalCode [1] IMPLICIT Integer16 OPTIONAL,
additionalDescription [2] IMPLICIT VisibleString OPTIONAL,
additionalInfo [3] IMPLICIT ANY OPTIONAL
}
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

12.2.4.2 Error class

ErrorClass ::= CHOICE {
noError [0] IMPLICIT Integer8 {
normal (0),
other (1)
}
applicationReference [1] IMPLICIT Integer8 {
other (0),
application-unreachable (1),
application-reference-invalid (2),
context-unsupported (3)
}
definition [2] IMPLICIT Integer8 {
other (0),
object-undefined (1),
object-attributes-inconsistent (2),
name-already-exists (3),
type-unsupported (4),
type-inconsistent (5)
}
resource [3] IMPLICIT Integer8 {
other (0),
memory-unavailable (1)
}
service [4] IMPLICIT Integer8 {
other (0),
object-state-conflict (1),
pdu-size (2),
object-constraint-conflict (3),
parameter-inconsistent (4),
illegal-parameter (5)
}
access [5] IMPLICIT Integer8 {
other (0),
object-invalidated (1),
hardware-fault (2),
object-access-denied (3),
invalid-address (4),
object-attribute-inconsistent (5),
object-access-unsupported (6),
object-non-existent (7),
type-conflict (8),
named-access-unsupported (9),
access-to-element-unsupported (10)
}
conclude [6] IMPLICIT Integer8 {
other (0)
}
other [7] IMPLICIT Integer8 {
other (0)
}
}

12.3 PDUs for ASEs

12.3.1 PDUs for Variable ASE

12.3.1.1 Read service PDUs

Read-RequestPDU ::= SEQUENCE {
objectSpecifier CHOICE{
variableSpecifier Gn_KeyAttribute,
variableListSpecifier Gn_KeyAttribute,
listOfvariable SEQUENCE OF Gn_KeyAttribute
}
optionalParameters [0] IMPLICIT ANY OPTIONAL
}

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Read-ResponsePDU ::= SEQUENCE {

result CHOICE{
accessStatus [0] IMPLICIT ErrorType,
listOfAccessStatus [1] IMPLICIT SEQUENCE OF ErrorType
}
value CHOICE{
data [0] IMPLICIT ANY,
listOfData [1] IMPLICIT SEQUENCE OF ANY
}
variableType CHOICE{
dataType [0] IMPLICIT Gn_FullyNestedTypeDescription OPTIONAL,
listOfDataType [1] IMPLICIT SEQUENCE OF Gn_FullyNestedTypeDescription
OPTIONAL
}
optionalParameters [0] IMPLICIT ANY OPTIONAL
}

12.3.1.2 Write service PDUs

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Write-RequestPDU ::= SEQUENCE {

objectSpecifier CHOICE{
variableSpecifier Gn_KeyAttribute,
variableListSpecifier Gn_KeyAttribute,
listOfVariable SEQUENCE OF Gn_KeyAttribute
}
variableType CHOICE{
dataType [0] IMPLICIT Gn_FullyNestedTypeDescription OPTIONAL,
listOfDataType [1] IMPLICIT SEQUENCE OF Gn_FullyNestedTypeDescription
OPTIONAL
}
value CHOICE{
data [0] IMPLICIT ANY,
listOfData [1] IMPLICIT SEQUENCE OF ANY
}
optionalParameters [0] IMPLICIT ANY OPTIONAL
}

Write-ResponsePDU ::= SEQUENCE {

result CHOICE{
accessStatus [0] IMPLICIT ErrorType,
listOfAccessStatus [1] IMPLICIT SEQUENCE OF ErrorType
}
optionalParameters [0] IMPLICIT ANY OPTIONAL
}

12.3.1.3 Information Report service PDUs

InformationReport-RequestPDU::= SEQUENCE {
ListOfVariableSpecifier CHOICE {
variableListSpecifier Gn_KeyAttribute,
listOfVariable SEQUENCE OF Gn_KeyAttribute
},
listOfDataType [1] IMPLICIT SEQUENCE OF Gn_FullyNestedTypeDescription
OPTIONAL
listOfData [2] IMPLICIT SEQUENCE OF ANY
optionalParameters [3] IMPLICIT ANY OPTIONAL
}

12.3.2 PDUs for Event ASE

12.3.2.1 Event Notification service

EventNotification-RequestPDU ::= SEQUENCE {
eventNotifierID IMPLICIT Gn_ KeyAttribute,,
notificvationSequenceNumber [1] IMPLICIT Ev_SequenceNumber,
listOfEvent [2] IMPLICIT SEQUENCE OF Ev_EventData,
Notification Time [3] IMPLICIT Ev_TimeTag OPTIONAL
optionalParameters [4] IMPLICIT ANY OPTIONAL
}

Copyright International Electrotechnical Commission

12.3.2.2 Notification Recovery service

EventRecovery-RequestPDU ::= SEQUENCE {
eventNotifierID IMPLICIT Gn_ KeyAttribute,,
sequenceNumber [1] IMPLICIT Ev_SequenceNumber OPTIONAL
}

12.3.3 PDUs for Load region ASE

12.3.3.1 Download service

DownLoad-RequestPDU ::= SEQUENCE {
loadRegionKeyAttribute Gn_KeyAttribute,
segmentIdentifier [1] IMPLICIT ANY,
loadData [2] IMPLICIT OctetString,
}

DownLoad-ResponsePDU ::= SEQUENCE {

loadRegionKeyAttribute Gn_KeyAttribute,
result [1] IMPLICIT ErrorType,
}

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
12.3.3.2 Upload service
UpLoad-RequestPDU ::= SEQUENCE {
loadRegionKeyAttribute Gn_KeyAttribute,
segmentIdentifier [1] IMPLICIT ANY,
}

UpLoad-ResponsePDU ::= SEQUENCE {

loadRegionKeyAttribute Gn_KeyAttribute,
result [1] IMPLICIT ErrorType,
loadData [2] IMPLICIT OctetString,
}

12.3.4 PDUs for Function Invocation ASE

12.3.4.1 Start service

Start-RequestPDU ::= SEQUENCE {
keyAttribute Gn_KeyAttribute,
optionalParameters [1] IMPLICIT ANY OPTIONAL
}

Start-ResponsePDU ::= ErrorType

12.3.4.2 Stop service

Stop-RequestPDU ::= SEQUENCE {
keyAttribute Gn_KeyAttribute,
optionalParameters [1] IMPLICIT ANY OPTIONAL
}

Stop-ResponsePDU ::= ErrorType

12.3.4.3 Resume services

Resume-RequestPDU ::= SEQUENCE {
keyAttribute Gn_KeyAttribute,
optionalParameters [1] IMPLICIT ANY OPTIONAL
}

Resume-ResponsePDU ::= ErrorType

Copyright International Electrotechnical Commission

12.3.5 PDUs for Time ASE

12.3.5.1 Time service

Time-RequestPDU ::= Time-PDU

Time-ResponsePDU ::= Time-PDU

TimeDistribute-RequestPDU ::= Time-PDU

Time-PDU ::= SEQUENCE {

timeControl [0] IMPLICIT Tm_TimeControl,
Stratum [1] IMPLICIT Unsigned8
PollInterval [2] IMPLICIT Tm_TimeValue1,
Precision [3] IMPLICIT Tm_TimeValue1,
rootDelay [4] IMPLICIT Tm_TimeValue2,
rootDispersion [5] IMPLICIT Tm_TimeValue2,
referenceIdentifier [6] IMPLICIT Tm_ReferenceID,
referenceTimestamp [7] IMPLICIT Tm_Time,
originateTimestamp [8] IMPLICIT Tm_Time,
receiveTimestamp [9] IMPLICIT Tm_Time,
transmitTimestamp [10] IMPLICIT Tm_Time,
}

SetTime-RequestPDU ::= SEQUENCE {

timeValue [0] IMPLICIT Tm_Time,
optionalParameters [1] IMPLICIT ANY OPTIONAL
}

12.3.6 PDUs for Network Management ASE

12.3.6.1 Network Management service

InDiag-RequestPDU ::= SEQUENCE {
nodeInformation [0] IMPLICIT Nm_NodeInformation,
nodeStatus [1] IMPLICIT Nm_NodeStatus,
nodePublicKey [2] IMPLICIT Nm_PublicKey,
llistOfPathStatus [3] IMPLICIT Nm_ListOfPathStatus
}

ExDiag-RequestPDU ::= SEQUENCE {

doaminInformation [0] IMPLICIT Nm_DoaminInformation,
domainStatus [1] IMPLICIT Nm_DoaminStatus,
domainPublicKey [2] IMPLICIT Nm_PublicKey,
masterPriority [3] IMPLICIT Unsigned8,
llistOfPathStatus [4] IMPLICIT Nm_ListOfPathStatus,
listOfNodeStatus [5] IMPLICIT SEQUENCE OF Nm_NodeStatus
}

StationStatusReport-RequestPDU ::= SEQUENCE {

nodeInformation [0] IMPLICIT Nm_NodeInformation,
nodeStatus [1] IMPLICIT Nm_NodeStatus
}

DomainStatusReport-RequestPDU ::= SEQUENCE {

doaminInformation [0] IMPLICIT Nm_DoaminInformation,
domainStatus [1] IMPLICIT Nm_DomainStatus
}

12.4 Type definitions

12.4.1 Variable ASE types

There are no types special for the Variable ASE.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

12.4.2 Event ASE types

Ev_SequenceNumber ::= Unsigned8

Ev_EventData ::= ANY

En_EventCount ::= Unsigned8

Ev_TimeTag ::= Unsigned16

12.4.3 Load Region ASE types

There are no types special for the Load Region ASE.

12.4.4 Function Invocation ASE types

There are no types special for the function Invocation ASE.

12.4.5 Time ASE types

Tm_TimeControl ::= BitString8 {
-- bit 8,7 LeapIndidator
-- bit 6-4 ProtocolVersion
-- bit 3-1 TimeMode
}

Tm_TimeValue1 ::= Unsigned32 -- eight-bit signed integer, in seconds to the nearest power of two

Tm_TimeValue2 ::= Unsigned32 -- 32-bit signed fixed-point number, in seconds

-- with fraction point between bits 15 and 16

Tm_ReferenceID ::= VisibleString4 -- identifies the particular reference source

Tm_Time ::= SEQUENCE{

Seconds [0] Unsigned32
SecondsFraction [2] Unsigned32
}

12.4.6 Network Management ASE types

Nm_NodeInformation ::= SEQUENCE {
NodeIdentifier [0] IMPLICIT Nm_NodeIdentifier,
NoOfInterfaces [1] IMPLICIT Integer8,
InterfaceID [2] IMPLICIT Unsigned8,
PerformanceClass SEQUENCE {
MasterPriority [11] IMPLICIT Unsigned8,
TransmissionClass [12] IMPLICIT Unsigned8,
ResponseClass [13] IMPLICIT Unsigned8,
TimePrecisionLevel [14] IMPLICIT Unsigned8,
}
configurationSUM [4] IMPLICIT Unsigned32,
localNodeTime [5] IMPLICIT Tm_Time,
diagInterval [6] IMPLICIT BinaryTime2,
stationCoefficeincy [7] IMPLICIT Unsigned16
}

Nm_NodeStatus ::= BitString8 {

-- bit 8 CPU-Status -- True: ready, False: not ready
-- bit 7 communication-status -- True: ready, False: not ready
-- bit 6 reserved-status -- True: reserved, False: not reserved
-- bit 5 redundancy-status -- True: on-service, False: stand-by
-- bit 4 linkStatusOfnterfaceB -- True: linked, False: not linked
-- bit 3 linkStatusOfnterfaceA -- True: linked, False: not linked
-- bit 2 statusOfNetworkB -- True: healthy, False: failed
-- bit 1 statusOfNetworkA -- True: healthy, False: failed
}

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Nm_PublicKey ::= Unsigned64

Nm_ListOfPathStatus ::= CompactBooleanArray -- True: healthy, False: failed

Nm_DoaminInformation ::= SEQUENCE {

NodeIdentifier [0] IMPLICIT Nm_NodeIdentifier,
NoOfInterfaces [1] IMPLICIT Integer8,
InterfaceID [2] IMPLICIT Unsigned8,
localNodeTime [3] IMPLICIT Tm_Time,
diagInterval [4] IMPLICIT BinaryTime2,
}

Nm_DomainStatus ::= BitString8 {

-- bit 8 statusOfNetworkB -- True: healthy, False: failed
-- bit 7 statusOfNetworkA -- True: healthy, False: failed
-- bit 6,5 StatusOfTimeSynchronization -- 00: not synchronized
-- 01: synchronized with the domain time master
-- 10: synchronized with the network time master
-- 11: synchronized with the external time source
-- bit 4-1 TimeGroup
}

Nm_NodeIdentifier ::= SEQUENCE {

DomainNumber [0] IMPLICIT Integer8,
StationNumber [1] IMPLICIT Integer8
}

12.4.7 General types

12.4.7.1 Gn_KeyAttribute
Gn_KeyAttribute ::= CHOICE {
-- When this type is specified, only the key attributes of the class referenced are valid.
numericID [0] IMPLICIT Gn_NumericID,
name [1] IMPLICIT Gn_Name,
listName [2] IMPLICIT Gn_Name,
numericAddress [4] IMPLICIT Gn_NumericAddress,
symbolicAddress [5] IMPLICIT Gn_SymbolicAddress
}

12.4.7.2 Gn_Name
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Gn_Name ::= OctetString

12.4.7.3 Gn_NumericAddress
Gn_NumericAddress ::= SEQUENCE {
startAddress [0] IMPLICIT Unsigned32, -- physical address of the starting location
length [1] IMPLICIT Unsigned16 -- octet length of a memory block
}

12.4.7.4 Gn_NumericID
Gn_NumericID ::= Unsigned16 -- The values of this parameter are unique within an AP.

12.4.7.5 Gn_SymbolicAddress
Gn_SymbolicAddress ::= VisibleString

Copyright International Electrotechnical Commission

12.4.7.6 Gn_FullyNestedTypeDescription
Gn_FullyNestedTypeDescription ::= CHOICE {
boolean [1] Unsigned8,
integer8 [2] Unsigned8,
integer16 [3] Unsigned8,
integer32 [4] Unsigned8,
unsigned8 [5] Unsigned8,
unsigned16 [6] Unsigned8,
unsigned32 [7] Unsigned8,
float32 [8] Unsigned8,
float64 [9] Unsigned8,
binaryDate [10] Unsigned8,
timeOfDay [11] Unsigned8,
timeDifference [12] Unsigned8,
universalTime [13] Unsigned8,
fieldbusTime [14] Unsigned8,
time [15] Unsigned8,
bitstring8 [16] Unsigned8,
bitstring16 [17] Unsigned8,
bitstring32 [18] Unsigned8,
visiblestring1 [19] Unsigned8,
visiblestring2 [20] Unsigned8,
visiblestring4 [21] Unsigned8,
visiblestring8 [22] Unsigned8,
visiblestring16 [23] Unsigned8,
octetstring1 [24] Unsigned8,
octetstring2 [25] Unsigned8,
octetstring4 [26] Unsigned8,
octetstring8 [27] Unsigned8,
octetstring16 [28] Unsigned8,
bcd [29] Unsigned8,
iso10646char [30] Unsigned8,
binarytime0 [31] Unsigned8,
binarytime1 [32] Unsigned8,
binarytime2 [33] Unsigned8,
binarytime3 [34] Unsigned8,
binarytime4 [35] Unsigned8,
binarytime5 [36] Unsigned8,
binarytime6 [37] Unsigned8,
binarytime7 [38] Unsigned8,
binarytime8 [39] Unsigned8,
binarytime9 [40] Unsigned8,
visiblestring [41] Unsigned8,
octetstring [42] Unsigned8,
bitstring [43] Unsigned8,
compactBooleanArray [44] Unsigned8,
compactBCDArray [45] Unsigned8,
iso646string [46] Unsigned8,
structure [47] IMPLICIT SEQUENCE OF Gn_FullyNestedTypeDescription
}

12.5 Data types

12.5.1 Notation for the Boolean type

Boolean ::= BOOLEAN -- TRUE if the value is non-zero.
-- FALSE if the value is zero.

12.5.2 Notation for the Integer type

Integer ::= INTEGER -- any integer
Integer8 ::= INTEGER (-128..+127) -- range -27 <= i <= 27-1
Integer16 ::= INTEGER (-32768..+32767) -- range -215 <= i <= 215-1
Integer32 ::= INTEGER -- range -231 <= i <= 231-1

12.5.3 Notation for the Unsigned type

Unsigned ::= INTEGER -- any non-negative integer
Unsigned8 ::= INTEGER (0..255) -- range 0 <= i <= 28-1
Unsigned16 ::= INTEGER (0..65535) -- range 0 <= i <= 216-1
Unsigned32 ::= INTEGER -- range 0 <= i <= 232-1

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

12.5.4 Notation for the Floating Point type

Floating32 ::= BIT STRING SIZE (4) -- IEC-60559Single precision
Floating64 ::= BIT STRING SIZE ( 8) -- IEC-60559Double precision

12.5.5 Notation for the BitString type

BitString ::= BIT STRING -- For generic use
BitString4 ::= BIT STRING SIZE (4) -- Fixed four bits bitstring
BitString8 ::= BIT STRING SIZE (8) -- Fixed eight bits bitstring
BitString16 ::= BIT STRING SIZE (16) -- Fixed 16 bits bitstring
BitString32 ::= BIT STRING SIZE (32) -- Fixed 32 two bits bitstring

12.5.6 Notation for the OctetString type

OctetString ::= OCTET STRING -- For generic use
OctetString2 ::= OCTET STRING SIZE (2) -- Fixed two-octet octet string
OctetString4 ::= OCTET STRING SIZE (4) -- Fixed four-octet octet string
OctetString6 ::= OCTET STRING SIZE (6) -- Fixed six-octet octet string
OctetString7 ::= OCTET STRING SIZE (7) -- Fixed seven-octet octet string
OctetString8 ::= OCTET STRING SIZE (8) -- Fixed eight-octet octet string
OctetString16 ::= OCTET STRING SIZE (16) -- Fixed 16 octet octet string

12.5.7 Notation for VisibleString type

VisibleString2 ::= VisibleString SIZE (2) -- Fixed two-octet visible string
VisibleString4 ::=VisibleString SIZE (4) -- Fixed four-octet visible string
VisibleString8 ::= VisibleString SIZE (8) -- Fixed eight-octet visible string
VisibleString16 ::= VisibleString SIZE (16) -- Fixed 16 octet visible string

12.5.8 Notation for the UNICODEString type

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
UNICODEString ::= UNICODEString -- 16-bit character code set defined in ISO 10646.

12.5.9 Notation for Binary Time type

BinaryTime0 ::= BIT STRING SIZE (16) -- 10 µs resolution
BinaryTime1 ::= BIT STRING SIZE (16) -- 0.1 ms resolution
BinaryTime2 ::= BIT STRING SIZE (16) -- 1 ms resolution
BinaryTime3 ::= BIT STRING SIZE (16) -- 10 ms resolution
BinaryTime4 ::= BIT STRING SIZE (16) -- 0.1 s resolution
BinaryTime5 ::= BIT STRING SIZE (16) -- 1 s resolution
BinaryTime6 ::= BIT STRING SIZE (32) -- 10 µs resolution
BinaryTime7 ::= BIT STRING SIZE (32) -- 0.1 ms resolution
BinaryTime8 ::= BIT STRING SIZE (32) -- 1 ms resolution
BinaryTime9 ::= BIT STRING SIZE (32) -- 10 ms resolution

12.5.10 Notation for BCD type

BCD ::= Unsigned8 (0..9) -- Lower four bits are used to express one BCD value.

12.5.11 Notation for Compact Boolean Array type

CompactBooleanArray ::= BitString -- Each zero bit representing Boolean value FALSE.
-- Each one bit representing Boolean value TRUE.
-- Unused bits, if any, shall be placed in bits 7-1 of the last octet.

12.5.12 Notation for Compact BCD Array type

CompactBCDArray ::= OctetString -- One BCD value is represented by four bits, an unused
-- nibble, if any, shall be placed in bits 4-1 of the last octet,
-- and shall be set to 1111F.

Copyright International Electrotechnical Commission

13 Transfer syntax

13.1 Overview of encoding

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

The FAL-PDUs encoded shall have a uniform format. The FAL-PDUs shall consist of two
major parts, the “APDU Header” part and the “APDU Body” part as shown in Figure 3.

(1) (1) (1) (n) --- Octets

FalArHeader Field Type Field (InvokeID) Service Specific Parameters
<------------------- APDU Header ----------------> <----------------- APDU Body ----------------->

NOTE The presence of the InvokeID Field depends on the APDU type.

Figure 3 – APDU overview

To realize an efficient APDU while maintaining flexible encoding, different encoding rules are
used for the APDU Header part and the APDU Body part.
NOTE The Data Link Layer service provides a DLSDU parameter that implies the length of the APDU. Thus, the
APDU length information is not included in the APDU.

13.2 APDU Header encoding

The APDU Header part is always present in all APDUs that conform to this standard. It
consists of three fields: the FalArHeader Field, the Type Field, and the optional InvokeID Field.

They are shown in Figure 3.

13.2.1 Encoding of FalArHeader Field

All the FAL PDUs shall have the common PDU-header called FalArHeader. The FalArHeader
identifies abstract syntax, transfer syntax, and each of the PDUs. Table 32 defines how this
header shall be used.

Table 32 – Encoding of FalArHeader Field

Bit position of the

FalArHeader PDU type Protocol Version
87 654 321
01 001 000 ConfirmedSend-CommandPDU Version 1
01 001 100 ConfirmedSend-ResponsePDU Version 1
01 010 000 UnconfirmedSend-CommandPDU Version 1
NOTE All other code points are reserved for additional protocols and future revisions.

13.2.2 Encoding of Type Field

a) The service type of an APDU is encoded in the Type Field that is always the second octet
of the APDUs.
b) All bits of the Type Field are used to encode the service type.
1) The service types shall be encoded in bits 8 to 1 of the Type Field, with bit 8 the most
significant bit and bit 1 the least significant bit. The range of service type shall be
between 0 (zero) and 254, inclusive.
2) The value of 255 is reserved for future extensions to this specification.
3) The service type is specified in the abstract syntax as a positive integer value.

Copyright International Electrotechnical Commission

c) Figure 4 illustrates the encoding of the Type Field.

8 7 6 5 4 3 2 1
Service Type

Figure 4 – Type Field

13.2.3 Encoding of InvokeID Field

The InvokeID Field shall be present if it is indicated in the abstract syntax. Otherwise, this
field shall not be present. If present, the InvokeID parameter supplied by a service primitive
shall be placed in this field.

13.3 APDU Body encoding

13.3.1 General

The FAL encoding rules are based on the terms and conventions defined in ISO/IEC 8825-1.
The encoding consists of three components in the following order:

Identifier Octet
Length Octet(s)
Contents Octet(s)
13.3.2 Identifier Octet

The Identifier Octet shall encode the tag defined in the FAL Abstract Syntax and shall consist
of one octet.

It consists of the P/C flag and the Tag field as shown in Figure 5.

8 7 6 5 4 3 2 1
P/C Tag field

Figure 5 – Identifier Octet

The P/C flag indicates that the Contents Octet(s) is either a simple component (primitive types,
such as Integer8), or a structured component (constructed, such as SEQUENCE, SEQUENCE
OF types).
P/C Flag =0 means the Contents Octet(s) is a simple component.
P/C Flag =1 means the Contents Octet(s) is a structured component.

The Tag field identifies the semantics of the Contents Octet(s).

13.3.3 Length Octet(s)

The Length Octet(s) shall consist of one or three octets.

a) If the value of the first Length Octet is other than 255, there shall be no subsequent
Length Octet(s) and the first octet shall contain the value for the Length Octet defined
later.
b) If the value of the first Length Octet is 255, there shall be two subsequent Length Octet(s)
that shall contain the values for the Length Octets defined later. In this case, the length
information of the Contents Octet(s) shall be represented by the last two octets of the
Length Octets, where the most significant bit of the second of three Length Octets shall be
the most significant bit of the length value and the least significant bit of the third of the
three Length Octets shall be the least significant bit of the length value.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

The sender shall have the option of using either the one-octet format or three-octet format.
For example, the three-octet format may be used to convey a length value of one.

The meaning of the Length Octet(s) depends on the type of value being encoded. If the
encoding of the Contents Octet(s) is primitive, the Length Octet(s) shall contain the number of
octets in the Contents Octets. If the encoding of the Contents Octets is constructed, the
Length Octet(s) shall contain the number of the first level components of the Contents Octets.

Figure 6 and Figure 7 depict encoding examples of the Length Octet(s):

8 7 6 5 4 3 2 1
(msb) value of the Length Octet as defined above (lsb)

Figure 6 – Length octet (one-octet format)

first octet 15 second and third octets 1

11111111 (msb) value of the Length Octets as defined above (lsb)

Figure 7 – Length octets (three-octet format)

13.3.4 Contents Octet(s)

The Contents Octet(s) shall encode the data value according to the encoding rule defined for
its type.

The Contents Octet(s) shall have either of the following two forms: primitive encoding or
constructed encoding.

a) If the Contents Octet(s) contain a primitive encoding, they represent an encoding of one
value.
b) If the Contents Octet(s) contain a constructed encoding, they represent an enumerated
encoding of more than one value.

13.4 Data type encoding rules

13.4.1 General

13.4.1.1 Boolean

A Boolean value shall be encoded as follows:

a) The Identifier Octet and the Length Octet(s) shall not be present.
b) The Contents Octet(s) component always consists of one octet. If the Boolean value
equals FALSE, all bits of the octet are 0. If the Boolean value equals TRUE, the octet can
contain any combination of bits other than the encoding for FALSE.

13.4.1.2 Integer

An Integer value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present if the size of the Integer value is invariable. An
integer with invariable size is created by constraining the possible value. The Length
Octet(s) shall be present if the size of the Integer value is variable.
c) The Contents Octet(s) shall contain the two’s complement binary number equal to the
Integer value. The most significant eight bits of the Integer value are encoded in bit 8 to
bit 1 of the first octet, the next eight bits in bit 8 to bit 1 of the next octet and so on. If the
values of an Integer type are restricted to negative and non-negative numbers, bit 8 of the
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

first octet gives the sign of the value if the values are restricted to non-negative numbers
only, no sign bit is needed.

13.4.1.3 Unsigned Value

An Unsigned Value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present if the size of the Unsigned Value is invariable.
The length of an Unsigned Value with invariable depends on the specified range of the
value. The Length Octet(s) shall be present if the size of the Unsigned Value is variable.
c) The Contents Octet(s) shall be a binary number equal to the Unsigned Value, and consist
of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet, followed by bits
8 to 1 of each octet in turn, up to and including the last octet of the Contents Octet(s).

13.4.1.4 Floating Point

A Floating Point value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present.
c) The Contents Octet(s) shall contain floating point values defined in conformance with the
IEC-60559 Standard. The sign is encoded by using bit 8 of the first octet. It is followed by
the exponent starting from bit 7 of the first octet, and then the mantissa starting from bit 7
of the second octet for Floating32 and from bit 4 of the second octet for Floating64.

13.4.1.5 Bit String

A Bit String value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present if the size of the Bit String value is invariable. A
Bit String with invariable size is created by applying a size constraint containing only one
value on the Bit String type. The Length Octet(s) shall be present if the size of the Bit
String value is variable.
c) The Contents Octet(s) comprise as many octets as necessary to contain all bits of the
actual value: N_Octets = (N_Bits-1) div 8 + 1. The Bit String value commencing with the
first bit and proceeding to the trailing bit shall be placed in bits 8 to 1 of the first octet,
followed by bits 8 to 1 of the second octet and so on. If the number of bits is not a multiple
of 8, there are so-called unused bits, which are located in the least significant bits of the
last octet. The value of the unused bits may be zero (0) or one (1) and carry no meaning.

13.4.1.6 Octet String

An Octet String value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present if the size of the Octet String value is invariable.
An Octet String with invariable size is created by applying a size constraint containing
only one value on the Octet String type. The Length Octet(s) shall be present if the size of
the Octet String value is variable.
c) The Contents Octet(s) shall be equal in value to the octets in the data value.

13.4.1.7 Visible String

A Visible String value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present if the size of the Visible String value is invariable.
A Visible String with invariable size is created by applying a size constraint containing
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

only one value on the Visible String type. The Length Octet(s) shall be present if the size
of the Visible String value is variable.
c) The Contents Octet(s) shall be equal in value to the octets in the data value.

13.4.1.8 UNICODE String (ISO 10646 String)

A UNICODE String value shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall indicate the number of octets in the Contents Octet(s) as a
binary number.
c) Each ISO10646 character shall be placed in two octets in the Contents Octet(s), with the
high-order octet placed in the first octet and the low-order octet in the subsequent octet,
and with the most significant bit of an octet of the data value aligned with the most
significant bit of an octet of the Contents Octet(s).

13.4.1.9 Binary Time

A Binary Time value shall be encoded as follows:

a) The Identifier Octet shall not be present

b) The Length Octet(s) shall not be present.
c) The Contents Octet(s) shall be a binary number equal to the Binary Time value, and
consisting of bits 8 to 1 of the first octet, followed by bits 8 to 1 of the second octet,
followed by bits 8 to 1 of each octet in turn, up to and including the last octet of the
Contents Octet(s).

13.4.1.10 BCD type

a) A BCD value shall be encoded as an Unsigned8 value.
b) A BCD value shall be placed in bits 4 to 1 of the Contents Octet of an Unsigned8 value.
The values of the bits 8 to 5 shall be zero (0).

13.4.1.11 Compact Boolean Array

A Compact Boolean Array value shall be encoded as a Bit String value.

13.4.1.12 Compact BCD Array type

a) A Compact BCD Array value shall be encoded as a primitive type.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

b) The Identifier Octet shall not be present.

c) The Length Octet(s) shall indicate the number of octets in the array as a binary number.
d) If the number of BCD values is zero, there shall be no subsequent octets, and the Length
Octet(s) shall be zero.
e) The first BCD value shall be placed as a binary number in bits 8 to 5 of the first Contents
Octet(s), and the second BCD value shall be placed in bits 4 to 1 of the first Contents
Octet(s). This will be repeated for the remaining BCD values and Contents Octet(s) up to
and including the last octet of the Contents Octet(s). The values of any unused bits in the
last Contents Octet shall be set to 1.

13.4.1.13 SEQUENCE type

A value of a SEQUENCE type shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall be present and specify the number of the first level components
of the Contents Octet(s). However, for the first Keyword “SEQUENCE” of FalArPDU, this
length shall not be encoded.

Copyright International Electrotechnical Commission

c) The Contents Octet(s) shall consist of the encodings of all the element types in the same
order as they are specified in the ASN.1 description of the SEQUENCE type.

13.4.1.14 SEQUENCE OF type

A value of a SEQUENCE OF type shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall be present and specify the number of the first level components
of the Contents Octet(s).
c) The Contents Octet(s) shall consist of the encodings of all the element types in the same
order as they are specified in the ASN.1 description of the SEQUENCE OF type.

13.4.1.15 CHOICE type

A value of a CHOICE type shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present.
c) The Contents Octet(s) shall consist of the encoding of the selected type of the alternative
type list.

13.4.1.16 Null

A value of a NULL type shall be encoded as follows:

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
a) The Identifier Octet shall not be present.
b) The Length Octet(s) shall not be present.
c) The Contents Octet(s) shall not be present.

13.4.1.17 Tagged type

A value of a Tagged type shall be encoded as follows:

a) The Identifier Octet shall only be present if the tagged type is a part of an alternative type
list in a CHOICE construct.
b) The Length Octet(s) shall not be present.
c) The Contents Octet(s) shall consist of the encoding of the type that was tagged.

13.4.1.18 IMPLICIT type

A value of an IMPLICIT type shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present.
c) The Contents Octet(s) shall consist of the encoding of the type being referenced by the
IMPLICIT construct, except for the case when the referenced type is a SEQUENCE type.
In this case, the Contents Octet(s) consist only of the Contents Octet(s) of the referenced
SEQUENCE type, and the Length Octet(s) of this SEQUENCE type shall not be present.

13.4.1.19 OPTIONAL and DEFAULT types

A value of an OPTIONAL or DEFAULT type shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall be present. If there is no value for this type, the Length Octet(s)
contain the value 0.
c) The Contents Octet(s) shall consist of the encoding of the referenced type if there is a
value for this type, otherwise no Contents Octets exist.

Copyright International Electrotechnical Commission

13.4.1.20 ANY type

An ANY type is used for the definition of complex types, whose structure is described
informally rather than in ASN.1.

A value of an ANY type shall be encoded as follows:

a) The Identifier Octet shall not be present.

b) The Length Octet(s) shall not be present.
c) The Contents Octets shall consist of the encoding of all implicit types that constitute the
ANY type.

14 FAL protocol state machines structure

This subclause specifies protocol machines of the FAL and the Interface between them.
NOTE The state machines specified in this subclause and ARPMs defined in the following sections only define the
protocol-related events for each. It is a local matter to handle other events.

The behaviour of the FAL is described by three integrated protocol machines. The three kinds
of protocol machines are: FAL Service Protocol Machines (FSPMs), the Application
Relationship Protocol Machines (ARPMs), and the Data Link Layer Mapping Protocol
Machines (DMPMs). Specific protocol machines are defined for different AREP types. The
relationships among these protocol machines as well as primitives exchanged among them
are depicted in Figure 8.

AP Cortext

FAL Service Req/Rsp Primitives FAL Service Ind/Cnf Primitives

FSPM

FSPM Req/Rsp Primitives FSPM Ind/Cnf Primitives

#n ARPM

#1 ARPM

ARPM Req/Rsp Primitives ARPM Ind/Cnf Primitives

DMPM

DL Req/Rsp Primitives DL Ind/Cnf Primitives

Data Link Layer

Figure 8 – Relationships among protocol machines and adjacent layers

The FSPM is responsible for the following activities:

a) to accept service primitives from the FAL service user and convert them into FAL internal
primitives;

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

b) to select an appropriate ARPM state machine based on the AREP Identifier parameter
supplied by the AP-Context and send FAL internal primitives to the selected ARPM;
c) to accept FAL internal primitives from the ARPM and convert them into service primitives
for the AP-Context;
d) to deliver the FAL service primitives to the AP-Context based on the AREP Identifier
parameter associated with the primitives.

The ARPM is responsible for the following activities:

a) to accept FAL internal primitives from the FSPM and create and send other FAL internal
primitives to either the FSPM or the DMPM, based on the AREP and primitive types;
b) to accept FAL internal primitives from the DMPM and send them to the FSPM in a
converted form for the FSPM;
c) if the primitives are for the Establish or Abort service, it shall try to establish or release the
specified AR.

The DMPM describes the mapping between the FAL and the DLL. It is common to all the
AREP types and does not have any state changes. The DMPM is responsible for the following
activities:

a) to accept FAL internal primitives from the ARPM, prepare DLL service primitives, and
send them to the DLL;
b) to receive DLL indication or confirmation primitives from the DLL and send them to the
ARPM in a converted form for the ARPM.

15 AP-Context state machine

There is no AP-Context State Machine defined for this Protocol.

16 FAL Service Protocol Machines (FSPMs)

16.1 General

There are FAL Service Protocol Machines as follows:

• Variable ASE Protocol Machine (VARM)

• Event ASE Protocol Machine (EVTM)
• Load Region ASE Protocol Machine (LDRM)
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

• Function Invocation ASE Protocol Machine (FNIM)

• Time ASE Protocol Machine (TIMM)
• Network Management ASE Protocol Machine (NWMM)

16.2 Common parameters of the primitives

Many services have the following parameters. Instead of defining them with each service, the
following common definitions are provided.

AREP
This parameter contains sufficient information to identify the AREP to be used to convey the
service. This parameter may use a key attribute of the AREP to identify the application
relationship. When an AREP supports multiple contexts (established using the Initiate service)
at the same time, the AREP parameter is extended to identify the context as well as the AREP.

Copyright International Electrotechnical Commission

InvokeID
This parameter identifies this invocation of the service. It is used to associate a service
request with its response. Therefore, no two outstanding service invocations can be identified
by the same InvokeID value.

Error Info
This parameter provides error information for service errors. It is returned in confirmed service
primitives and response primitives.

16.3 Variable ASE Protocol Machine (VARM)

16.3.1 Primitive definitions

16.3.1.1 Primitives exchanged

Table 33 shows the service primitives, including their associated parameters exchanged
between the FAL user and the VARM.

Table 33 – Primitives exchanged between FAL user and VARM

Primitive Source Associated Functions

name parameters
Read.req FAL VariableSpecifier This primitive is used to read values from remote
User variables.
Write.req FAL VariableSpecifier This primitive is used to write values to remote
User variables.
InfReport.req FAL VariableSpecifier, This primitive is used to publish variables.
User Value,
RemoteArep
Read.rsp FAL VariableSpecifier, This primitive is used to convey values of variables
User Value, requested.
ErrorInfo
Write.rsp FAL VariableSpecifier, This primitive is used to report result of writing
User ErrorInfo requested.
Read.ind VARM VariableSpecifier This primitive is used to convey a read request.
Write.ind VARM VariableSpecifier This primitive is used to convey a write request.
Value
InfReport.ind VARM VariableSpecifier, This primitive is used to report values of variables
Value published.
Read.cnf VARM VariableSpecifier, This primitive is used to convey values of variables
Value requested and result of reading.
ErrorInfo
Write.cnf VARM VariableSpecifier, This primitive is used to report result of writing
ErrorInfo requested.

16.3.1.2 Parameters of primitives

The parameters used with the primitives exchanged between the FAL user and the VARM are
listed in Table 34.

Table 34 – Parameters used with primitives exchanged FAL user and VARM

Parameter name Description

VariableSpecifier This parameter specifies a variable or a variable list.
RemoteArep This parameter specifies a remote AREP to which APDU is to be transferred.
Value This parameter contains the value of variable to be read/write.
ErrorInfo This parameter provides error information for service errors.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

16.3.2 State machine

16.3.2.1 General

The VARM State Machine has only one possible state: ACTIVE.

Copyright International Electrotechnical Commission

ACTIVE All transitions

Figure 9 – State transition diagram of VARM

16.3.2.2 State tables

The VARM state machine is described in Figure 9, and in Table 35 and Table 36.

Table 35 – VARM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 ACTIVE Read.req ACTIVE
=>
ArepID := GetArep(VariableSpecifier)
SelectArep(ArepID, “PTC-AR”),
CS_req{

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
user_data := Read-RequestPDU
}
S2 ACTIVE Write.req ACTIVE
=>
ArepID := GetArep(VariableSpecifier)
SelectArep(ArepID, “PTC-AR”),
CS_req{
user_data := Write-RequestPDU
}
S3 ACTIVE InfReport.req ACTIVE
=>
SelectArep(RemoteArep, “MSU-AR”),
UCS_req{
user_data := InformationReport-RequestPDU
}
S4 ACTIVE Read.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
user_data := Read-ResponsePDU
}
S5 ACTIVE Write.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
user_data := Write-ResponsePDU
}

Copyright International Electrotechnical Commission

Table 36 – VARM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 ACTIVE CS_ind ACTIVE
&& PDU_Type = Read_RequestPDU
=>
Read.ind{
ArepID := arep_id
Data := user_data
}
R2 ACTIVE CS_ind ACTIVE
&& PDU_Type = Write_RequestPDU
=>
Write.ind{
ArepID := arep_id
Data := user_data,
}
R3 ACTIVE CS_ind ACTIVE
&& PDU_Type = Read_ResponsePDU
&& GetErrorInfo() = “success”
=>
Read.cnf(+){
Data := user_data
}
R4 ACTIVE CS_ind ACTIVE

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
&& PDU_Type = Read_ResponsePDU
&& GetErrorInfo() <> “success”
=>
Read.cnf(-){
ErrorInfo := GetErrorInfo()
}
R5 ACTIVE CS_ind ACTIVE
&& PDU_Type =Write_ResponsePDU
&& GetErrorInfo() = “success”
=>
Write.cnf(+){
Data := user_data
}
R6 ACTIVE CS_ind ACTIVE
&& PDU_Type = Write_ResponsePDU
&& GetErrorInfo() <> “success”
=>
Write.cnf(-){
ErrorInfo := GetErrorInfo()
}
R7 ACTIVE UCS_ind ACTIVE
&& PDU_Type = InformationReport-RequestPDU
=>
InfReport.ind{
Data := user_data
}
R8 ACTIVE CS_cnf ACTIVE
&& Status = “success”
=>
(no actions taken)
R9 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Read”
=>
Read.cnf(-){
ErrorInfo := Status
}
R10 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Write”
=>
Write.cnf(-){
ErrorInfo := Status
}

Copyright International Electrotechnical Commission

16.3.2.3 Functions

Table 37 lists the functions used by the VARM, their arguments and their descriptions.

Table 37 – Functions used by the VARM

Function name Parameter Description

SelectArep ArepID, Looks for the AREP entry that is specified by the ArepID and
ARtype AR type.
GetArep VariableSpecifier Look for the ArepID based on the specified VariableSpecifier.
GetErrorInfo Gets error information from the APDU.
GetService InvokeID Gets service name from the InvokeID.

16.4 Event ASE Protocol Machine (EVTM)

16.4.1 Primitive definitions

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
16.4.1.1 Primitives exchanged

Table 38 shows the service primitives, including their associated parameters exchanged
between the FAL user and the EVTM.

Table 38 – Primitives exchanged between FAL user and EVTM

Primitive name Source Associated parameters Functions

Notification.req FAL AREP This primitive is used to request publishing of
User NotifierID event messages.
Sequence Number
ListOfEventMessages
EventRecovery.req FAL AREP This primitive is used to request retransmission
User NotifierID of event notification.
SequenceNumber
Notification.ind EVTM AREP This primitive is used to inform event notification.
NotifierID
SequenceNumber
List of Event Messages
EventRecovery.ind EVTM AREP This primitive is used to inform request of
NotifierID retransmission of event notification.
SequenceNumber

16.4.1.2 Parameters of primitives

The parameters used with the primitives exchanged between the FAL user and the EVTM are listed
in Table 39.
Table 39 – Parameters used with primitives exchanged FAL user and EVTM

Parameter name Description

NotifierID This conditional parameter identifies the notifier issuing the event notification. It is
present if the AP has more than one notifier defined for it.
SequenceNumber This optional parameter is the sequence number for the event notification. It may be
used for notification recovery purposes.
NotificationTime This optional parameter is the time tag for the event notification.
ListOfEventMessages This parameter contains the list of event messages that are to be reported. It may
contain messages from one or more event objects, and each object contains the same
set of parameters.

16.4.2 State machine

16.4.2.1 General

The EVTM State Machine has only one possible state: ACTIVE.

Copyright International Electrotechnical Commission

ACTIVE All transitions

Figure 10 – State transition diagram of EVTM

16.4.2.2 State tables

The EVTM state machine is described in Figure 10, and in Table 40 and Table 41.

Table 40 – EVTM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 ACTIVE Notification.req ACTIVE
=>
SelectArep(RemoteArep, “MTU-AR”),
UCS_req{
user_data := Event-NotificationPDU
}
S2 ACTIVE EventRecovery.req ACTIVE
=>
SelectArep(RemoteArep, “PTU-AR”),
UCS_req{
arep := SelectArep(CalledAREP, “PTU-AR”),
user_data := EventRecovery-RequestPDU
}

Table 41 – EVTM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 ACTIVE UCS_ind ACTIVE
&& PDU_Type = Event_NotifiationPDU
=>
Notification.ind{
Data := user_data
}
R2 ACTIVE UCS_ind ACTIVE
&& PDU_Type = EventRecovery-RequestPDU
=>
EventRecovery.ind {
Data := user_data
}

16.4.2.3 Functions

Table 42 lists the function used by the EVTM, their arguments, and their description.

Table 42 – Functions used by the EVTM

Function name Parameter Description

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

SelectArep ArepID, Looks for the AREP entry that is specified by the ArepID and
ARtype AR type.

Copyright International Electrotechnical Commission

16.5 Load Region ASE Protocol Machine (LDRM)

16.5.1 Primitive definitions

16.5.1.1 Primitives exchanged

Table 43 shows the service primitives, including their associated parameters exchanged
between the FAL user and the LDRM.

Table 43 – Primitives exchanged between FAL user and LDRM

Primitive Source Associated Functions

name parameters
Download.req FAL AREP This primitive is used to request download data to
User InvokeID the region.
LoadRegion
LoadData
Upload.req FAL AREP This primitive is used to request upload data from
User InvokeID the region.
LoadRegion
Download.rsp FAL AREP This primitive is used to report result of download
User InvokeID requested.
Error Info
Upload.rsp FAL AREP This primitive is used to convey data to be
User InvokeID uploaded.
LoadData
ErrorInfo
Download.ind LDRM AREP This primitive is used to convey data downloaded.
InvokeID
LoadRegion
LoadData
Upload.ind LDRM AREP This primitive is used to convey an upload request.
InvokeID
Load region
Download.cnf LDRM AREP This primitive is used to convey a result of
InvokeID download.
ErrorInfo
Upload.cnf LDRM AREP This primitive is used to convey data uploaded.
InvokeID
LoadData
ErrorInfo
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

16.5.1.2 Parameters of primitives

The parameters used with the primitives exchanged between the FAL user and the LDRM are
listed in Table 44.

Table 44 – Parameters used with primitives exchanged FAL user and LDRM

Parameter name Description

LoadRegion This parameter specifies the region from/to which the image is to be loaded.
LoadData This parameter contains the data to be loaded.
ErrorInfo This parameter provides error information for service errors.

16.5.2 State machine

16.5.2.1 General

The LDRM State Machine has only one possible state: ACTIVE.

Copyright International Electrotechnical Commission

ACTIVE All transitions

Figure 11 – State transition diagram of LDRM

16.5.2.2 State tables

The LDRM state machine is described in Figure 11, and in Table 45 and Table 46.

Table 45 – LDRM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 ACTIVE Download.req ACTIVE
=>
SelectArep(RemoteArep, “PTC-AR”),
CS_req{
user_data := DownLoad-RequestPDU
}
S2 ACTIVE Upload.req ACTIVE
=>
SelectArep(RemoteArep, “PTC-AR”),
CS_req{
user_data := UpLoad-RequestPDU
}
S3 ACTIVE Download.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
arep := SelectArep(CallingAREP, “PTC-AR”),
user_data := DownLoad-ResponsePDU
}
S4 ACTIVE Upload.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
arep := SelectArep(CallingAREP, “PTC-AR”),
user_data := UpLoad-ResponsePDU
}

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 46 – LDRM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 ACTIVE CS_ind ACTIVE
&& PDU_Type = DownLoad-RequestPDU
=>
Download.ind {
ArepID := arep_id
Data := user_data
}
R2 ACTIVE CS_ind ACTIVE
&& PDU_Type = UpLoad-RequestPDU
=>
Upload.ind {
ArepID := arep_id
Data := user_data
}
R3 ACTIVE CS_ind ACTIVE
&& PDU_Type = DownLoad-ResponsePDU
=>
Download.cnf(+) {
Data := user_data
}
R4 ACTIVE CS_ind ACTIVE
&& PDU_Type = UpLoad-ResponsePDU
=>
Upload.cnf(+) {
Data := user_data
}
R5 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Download”
=>
Download.cnf(-) {
ErrorInfo := Status
}
R6 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Upload”
=>
Upload.cnf(-) {
ErrorInfo := Status
}

16.5.2.3 Functions

Table 47 lists the functions used by the LDRM, their arguments, and their descriptions.

Table 47 – Functions used by the LDRM

Function name Parameter Description

SelectArep ArepID, Looks for the AREP entry that is specified by the ArepID
ARtype and AR type.
GetErrorInfo Gets error information from the APDU.
GetService InvokeID Gets service name from the InvokeID.

16.6 Function Invocation ASE Protocol Machine (FNIM)

16.6.1 Primitive definitions

16.6.1.1 Primitives exchanged

Table 48 shows the service primitives, including their associated parameters exchanged
between the FAL user and the FNIM.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 48 – Primitives exchanged between FAL user and FNIM

Primitive Source Associated Functions

name parameters
Start.req FAL AREP This primitive is used to request start of the
User InvokeID function.
FunctionID
Stop.req FAL AREP This primitive is used to request stop of the
User InvokeID function.
FunctionID
Resume.req FAL AREP This primitive is used to request resume of the
User InvokeID function.
FunctionID
Start.rsp FAL AREP This primitive is used to report result of start
User InvokeID requested.
Error Info
Stop.rsp FAL AREP This primitive is used to report result of stop
User InvokeID requested.
Error Info
Resume.rsp FAL AREP This primitive is used to report result of Resume
User InvokeID requested.
Error Info

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Start.ind FNIM AREP This primitive is used to convey a start request.
InvokeID
FunctionID
Stop.ind FNIM AREP This primitive is used to convey a stop request.
InvokeID
FunctionID
Resume.ind FNIM AREP This primitive is used to convey a resume request.
InvokeID
FunctionID
Start.cnf FNIM AREP This primitive is used to convey a result of start.
InvokeID
Error Info
Stop.cnf FNIM AREP This primitive is used to convey a result of stop.
InvokeID
Error Info
Resume.cnf FNIM AREP This primitive is used to convey a result of resume.
InvokeID
Error Info

16.6.1.2 Parameters of primitives

The parameter used with the primitives exchanged between the FAL user and the FNIM is
listed in Table 49.

Table 49 – Parameters used with primitives exchanged FAL user and FNIM

Parameter name Description

FunctionID This parameter specifies one of the key attributes of the function invocation object.

16.6.2 State machine

16.6.2.1 General

The FNIM State Machine has only one possible state: ACTIVE.

ACTIVE All transitions

Figure 12 – State transition diagram of FNIM

Copyright International Electrotechnical Commission

16.6.2.2 State tables

The FNIM state machine is described in Figure 12, and in Table 50 and Table 51.

Table 50 – FNIM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 ACTIVE Start.req ACTIVE
=>
SelectArep(RemoteArep, “PTC-AR”),
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

CS_req{
user_data := Start-RequestPDU
}
S2 ACTIVE Stop.req.req ACTIVE
=>
SelectArep(RemoteArep, “PTC-AR”),
CS_req{
user_data := Stop-RequestPDU
}
S3 ACTIVE Resume.req ACTIVE
=>
SelectArep(RemoteArep, “PTC-AR”),
CS_req{
user_data := Resume-ResponsePDU
}
S4 ACTIVE Start.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
user_data := Start-ResponsePDU
}
S5 ACTIVE Stop.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
user_data := Stop-ResponsePDU
}
S6 ACTIVE Resume.rsp ACTIVE
=>
SelectArep(ArepID, “PTC-AR”),
CS_rsp{
user_data := Resume-ResponsePDU
}

Table 51 – FNIM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 ACTIVE CS_ind ACTIVE
&& PDU_Type = Start-RequestPDU
=>
Start.ind {
Data := user_data
}
R2 ACTIVE CS_ind ACTIVE
&& PDU_Type = Stop-RequestPDU
=>
Stop.ind {
Data := user_data
}
R3 ACTIVE CS_ind ACTIVE
&& PDU_Type = Resume-RequestPDU
=>
Resume.ind {
Data := user_data
}

Copyright International Electrotechnical Commission

# Current Event or condition Next state

state
=> action
R4 ACTIVE CS_ind ACTIVE
&& PDU_Type = Start-ResponsePDU
=>
Start.cnf(+) {
Data := user_data
}
R5 ACTIVE CS_ind ACTIVE
&& PDU_Type = Start-ResponsePDU
&& GetErrorInfo() <> “success”
=>
Start.cnf(-){
ErrorInfo := GetErrorInfo()
}
R6 ACTIVE CS_ind ACTIVE
&& PDU_Type = Stop-ResponsePDU
=>
Stop.cnf(+) {
Data := user_data
}
R7 ACTIVE CS_ind ACTIVE
&& PDU_Type = Stop-ResponsePDU
&& GetErrorInfo() <> “success”
=>
Stop.cnf(-){
ErrorInfo := GetErrorInfo()
}
R8 ACTIVE CS_ind ACTIVE
&& PDU_Type = Resume-ResponsePDU
=>
Resume.cnf(+) {
Data := user_data
}
R9 ACTIVE CS_ind ACTIVE
&& PDU_Type = Resume-ResponsePDU
&& GetErrorInfo() <> “success”
=>
Resume.cnf(-){
ErrorInfo := GetErrorInfo()
}
R10 ACTIVE CS_cnf ACTIVE
&& Status = “success”
=>
(no actions taken)
R11 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Start”
=>
Start.cnf(-) {
ErrorInfo := Status
}
R12 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Stop”
=>
Stop.cnf(-) {
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

ErrorInfo := Status
}
R13 ACTIVE CS_cnf ACTIVE
&& Status <> “success”
&& GetService(InvokeID) = “Resume”
=>
Resume.cnf(-) {
ErrorInfo := Status
}

16.6.2.3 Functions

Table 52 lists the functions used by the FNIM, their arguments, and their descriptions.

Copyright International Electrotechnical Commission

Table 52 – Functions used by the FNIM

Function name Parameter Description

SelectArep AREPid, Looks for the AREP entry that is specified by the AREPid and
ARtype AR type.
GetErrorInfo Gets error information from the APDU.
GetService InvokeID Gets service name from the InvokeID.

16.7 Time ASE Protocol Machine (TIMM)

16.7.1 Primitive definitions

16.7.1.1 Primitives exchanged

Table 53 shows the service primitives, including their associated parameters exchanged
between the FAL user and the TIMM.

Table 53 – Primitives exchanged between FAL user and TIMM

Primitive Source Associated Functions

name parameters
GetTime.req FAL AREP This primitive is used to request network time.
User InvokeID
SetTim.req FAL AREP This primitive is used to request setting of time to
User InvokeID the network.
NetworkTime
SetTim.ind TIMM AREP This primitive is used to report setting of network
InvokeID time.
Network-time
Tick.ind TIMM Tick This primitive is used to report periodical trigger
synchronized to network time.
GetTim.cnf TIMM AREP This primitive is used to convey a result of getting of
InvokeID network time.
NetworkTime
ErrorInfo
SetTim.cnf TIMM AREP This primitive is used to convey a result of setting of
InvokeID network time.
ErrorInfo

16.7.1.2 Parameters of primitives

The parameters used with the primitives exchanged between the FAL user and the TIMM are
listed in Table 54.

Table 54 – Parameters used with primitives exchanged FAL user and TIMM

Parameter name Description

NetworkTime This parameter is the value of the network time.
ErrorInfo This parameter provides error information for service errors.
Tick This parameter indicates tick timing.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

16.7.2 State machine

16.7.2.1 General

The TIMM State Machine has four possible states. The defined states and their descriptions
are shown in Table 55 and Figure 13.

Copyright International Electrotechnical Commission

Table 55 – TIMM states

State Description

TIM_MST TIMM is acting as network time master.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
DOM_MST TIMM is acting as domain time master.
SLAVE TIMM is synchronized with domain time master.
IDLE TIMM is not synchronized with network time.

IDLE
S1, S3

SLAVE
S2, S3, S4
R2, R3, R4
R5

R12
R8
DOM- TIM-
S2, S3 R9
MST MST S2, S3
S5, S6
R2, R6, R7 R2, R10

R11

Figure 13 – State transition diagram of TIMM

16.7.2.2 State tables

The TIMM state machine is described in Figure 13, and in Table 56 and Table 57.

Table 56 – TIMM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 IDLE GetTime.req IDLE
=>
GetTime.cnf {
Error info := “not synchronized”
}
S2 SLAVE GetTime.req SAME
DOM_MST =>
TIM_MST GetTime.cnf {
NetworkTime := GetLocalTime()
}
S3 ANY SetTim.req SAME
=>
SelectArep(“NET”, “MTU-AR”),
UCS_req {
user_data := SetTime-RequestPDU
}
S4 SLAVE CheckTimer(Timer1) = “Expired” SLAVE
=>
SelectArep (“DOM-MST”, “PTC-AR”),
CS_req {
user_data := Time-RequestPDU
},
StartTimer(Timer1)

Copyright International Electrotechnical Commission

# Current Event or condition Next state

state
=> action
S5 DOM-MST CheckTimer(Timer2) = “Expired” DOM-MST
=>
SelectArep(“DOM”, “MTU-AR”),
UCS_req {
user_data := TimeDistribute-RequestPDU
},
StartTimer(Timer2)
S6 DOM-MST CheckTimer(Timer3) = “Expired” DOM-MST
=>
SelectArep(“TIM-MST”, “PTC-AR”),
CS_req {
user_data := Time-RequestPDU
},
StartTimer(Timer3)

Table 57 – TIMM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 IDLE UCS_ind SLAVE
&& PDU_Type = TimeDistribute-RequestPDU
=>
R2 SLAVE CheckTimer(Tick) = “Expired” SAME
DOM_MST =>
TIM_MST Tick.ind {}
StartTimer(Tick)
R3 SLAVE UCS_ind SLAVE
&& PDU_Type = TimeDistribute-RequestPDU
=>
UpdateLocalTime(DelayFactor)
R4 SLAVE CS_ind SLAVE
&& PDU_Type = Time-ResponsePDU
=>
DelayFactor = CalcurateDelay()
R5 SLAVE CheckNW() == DOM-MST DOM-MST
=>
(no actions taken)
R6 DOM-MST CS_ind DOM-MST
&& PDU_Type = Time-RequestPDU
=>
SelectArep(CallingAREP, “PTC-AR”),
CS_rsp {
user_data := Time-ResponsePDU
}
R7 DOM-MST CS_ind DOM-MST
&& PDU_Type = Time-ResponsePDU
=>
DelayFactor = CalcurateDelay(),
UpdateLocalTime(DelayFactor)
R8 DOM-MST CheckNW() == SLAVE SLAVE
=>
(no actions taken)
R9 DOM-MST CheckNW() == TIM-MST TIM-MST
=>
(no actions taken)
R10 TIM-MST CS_ind TIM-MST
&& PDU_Type = Time-RequestPDU
=>
SelectArep(CallingAREP, “PTC-AR”),
CS_rsp {
user_data := Time-ResponsePDU
}
R11 TIM-MST CheckNW() == DOM-MST DOM-MST
=>
(no actions taken)
R12 TIM-MST CheckNW() == SLAVE SLAVE
=>
(no actions taken)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

16.7.2.3 Functions

Table 58 lists the functions used by the TIMM, their arguments, and their descriptions.

Table 58 – Functions used by the TIMM

Function name Parameter Description

SelectArep ArepID, Looks for the AREP entry that is specified by the ArepID
ARtype and AR type.
The value “DOM” for ArepID specifies all stations of the
domain to which the NWMM is belong.
The value “NET” for ArepID specifies all station of the
network.
The value “DOM-MST” for ArepID specifies AREP of the
domain time master of the domain to which the NWMM is
belong.
The value “TIM-MST” for ArepID specifies AREP of the
network time master.
GetLocalTime Gets local time from the internal clock.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

UpdateLocalTime DelayFactor Updates local clock with the received time and the delay
factor.
CalcurateDelay Calculate the delay factor from received APDU.
CheckTimer TimerID Checks status of the specified timer. If the timer has been
expired, the value “Expired” is returned.
StartTimer TimerID Starts the timer specified.

16.8 Network Management ASE Protocol Machine (NWMM)

16.8.1 Primitive definitions

16.8.1.1 Primitives exchanged

Table 59 shows the service primitives, including their associated parameters exchanged
between the FAL user and the NWMM.

Table 59 – Primitives exchanged between FAL user and NWMM

Primitive Source Associated Functions

name parameters

GetNW.req FAL InvokeID This primitive is used to request network status.

User
GetSTN.req FAL InvokeID This primitive is used to request station status.
User
StationID
NWStatus.ind NWMM NetworkStatus This primitive is used to report changes of network
status.
STNStats.ind NWMM StationID This primitive is used to report changes of station
status.
StationStatus
RouteStatus
GetNW.cnf NWMM InvokeID This primitive is used to convey network status.
NetworkStatus
GetSTN.cnf NWMM InvokeID This primitive is used to convey station status
requested.
StationStatus
RouteStatus

16.8.1.2 Parameters of primitives

The parameters used with the primitives exchanged between the FAL user and the NWMM
are listed in Table 60.

Copyright International Electrotechnical Commission

Table 60 – Parameters used with primitives exchanged FAL user and NWMM

Parameter name Description

StationID This parameter indicates a station.
StationStatus This parameter indicates status of station which is specified in the request primitive.
RouteStatus This parameter indicates status of routes for the station which is specified in the request
primitive.
NetworkStatus This parameter indicates consistency of the primary network and the secondary network.

16.8.2 State machine

16.8.2.1 General

The NWMM State Machine has three possible states. The defined states and their
descriptions are shown in Table 61 and Figure 14.

Table 61 – NWMM states

State Description

MST NWMM is acting as a domain master.

SLAVE NWMM is acting as a slave.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
SLAVE MST
S1, S2, S3 S1, S2, S4
R1, R2 R1, R2

Figure 14 – State transition diagram of NWMM

Copyright International Electrotechnical Commission

16.8.2.2 State tables

The NWMM state machine is described in Figure 14, and in Table 62 and Table 63.

Table 62 – NWMM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 ANY GetNW.req SAME
=>
GetNW.cnf{
NetworkStatus := GetNWstatus()
}
S2 ANY GetSTN.req SAME
=>
GetSTN.cnf{
StationStatus := GetSTNstatus(StationID)
RouteStatus := GetRoutestatus(StationID)
}
S3 SLAVE CheckTimer(DiagTimer) SLAVE
=>
SelectArep(“DOM”, “MTU-AR”),
UCS_req{
user_data := InDiag-RequestPDU
},
StartTimer(DiagTimer)
S4 MST CheckTimer(DiagTimer) MST
=>
SelectArep(“DOM”, “MTU-AR”),
UCS_req{
user_data := InDiag-RequestPDU
}
SelectArep(“NET”, “MTU-AR”)
UCS_req{
user_data := ExDiag-Request PDU
},
StartTimer(DiagTimer)

Table 63 – NWMM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 ANY UCS_ind SAME
&& (PDU_Type = InDiag-RequestPDU
|| PDU_Type = ExDiag-RequestPDU)

=>
UpdateNWstatus()

CheckNWstatus(NWstatus-table) = “True”
=>
NWStatus.ind{
NetworkStatus := GetNWstatus()
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

(changedSTN := CheckSTNstatus(NWstatus-table)) <> “None”

=>
STNStats.ind {
StationID := changed-station,
StationStatus := GetSTNstatus(StationID)
RouteStatus := GetRouteStatus(StationID)
}

Copyright International Electrotechnical Commission

# Current Event or condition Next state

state
=> action
R2 ANY CheckTimer(AgingTimer) = “Expired” SAME
=>
UpdateNWstatus()

(changedSTN := CheckSTNstatus(NWstatus-table)) <> “None”

=>
STNStats.ind {
StationID := changed-station,
StationStatus := GetSTNstatus(StationID)
RouteStatus := GetRouteStatus(StationID)
},
StartTimer(AgingTimer)
R3 SLAVE CheckMaster(NWstatus-table) = “True” MST
=>
(no actions taken)
R4 MST CheckMaster (NWstatus-table) = “False” SLAVE
=>
(no actions taken)

16.8.2.3 Functions

Table 64 lists the functions used by the NWMM, their arguments, and their descriptions.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Table 64 – Functions used by the NWMM

Function name Parameter Description

GetNWstatus NWstatus-table Gets network status from the network status table.
GetSTNstatus NWstatus- Gets station status of the specified station from the
table,StationID network status table.
GetRoutestatus NWstatus-table, Gets route status to the specified station from the network
StationID status table.
SelectArep ArepID, Looks for the AREP entry that is specified by the ArepID
ARtype and AR type.
The value “DOM” for ArepID specifies all stations of the
domain to which the NWMM is belong.
The value “NET” for ArepID specifies all station of the
network.
CheckTimer TimerID Checks status of the specified timer. If the timer has been
expired, the value “Expired” is returned.
StartTimer TimerID Starts the timer specified.
UpdateNWstatus NWstatus-table Updates the network status table according to received
APDU,
If aging time of each entry of the network status table has
been expired, then updates the entry as not valid.
CheckNWstatus() NWstatus-table Checks the network status table. If any change of network
status is detected, the value “True” is returned.
CheckSTNstatus() NWstatus-table Checks the network status table. If any change of station
status is detected, the StationID of the detected station is
returned.
CheckMaster NWstatus-table Check the network status table. If the NWMM of own
station is recognized as master of the domain according
to the predefined rules, the value “True” is returned.

17 Application Relationship Protocol Machines (ARPMs)

17.1 General

This fieldbus has Application Relationship Protocol Machines (ARPMs) for:

• Point-to-point user-Triggered Confirmed client/server AREP (PTC-AR)

• Point-to-point user-Triggered Unconfirmed client/server AREP (PTU-AR)
• Point-to-point network-Scheduled Unconfirmed client/server AREP (PSU-AR)

Copyright International Electrotechnical Commission

• Multipoint user-Triggered Unconfirmed publisher/subscriber AREP (MTU-AR)

• Multipoint network-Scheduled Unconfirmed publisher/subscriber AREP (MSU-AR)

17.2 Primitive definitions

17.2.1 Primitives exchanged

Table 65 lists the primitives, including their associated parameters exchanged between the FSPM
and the ARPM.

Table 65 – Primitives exchanged between FSPM and ARPM

Primitive Source Associated parameters Functions

name
EST_req FSPM Remote_dlsap_address This primitive is used to request
establishment of the AR.
ABT_req FSPM Reason_code This primitive is used to request abort of the
AR.
CS_req FSPM Destination_dlsap_address, This primitive is used to request sending of
InvokeID, the ConfirmedSend-CommandPDU.
User_data,
UCS_req FSPM Remote_dlsap_address, This primitive is used to request sending of
User_data the UnconfirmedSend-CommandPDU.
CS_rsp FSPM Source_dlsap_address, This primitive is used to request sending of
User_data the ConfirmedSend-ResponsePDU.
CS_ind ARPM Source_dlsap_address, This primitive is used to report the received
InvokeID, ConfirmedSend-CommandPDU.
User_data
UCS_ind ARPM Remote_dlsap_address, This primitive is used to report the received
InvokeID, UnconfirmedSend-CommandPDU.
User_data
EST_cnf ARPM InvokeID, This primitive is used to convey a result of
Result, AR establishment.
CS_cnf ARPM InvokeID, This primitive is used to convey a result of
Result, confirmed sending.

17.2.2 Parameters of primitives

The parameters used with the primitives exchanged between the FSPM and the ARPM are
listed in Table 66.

Table 66 – Parameters used with primitives exchanged FSPM user and ARPM

Parameter name Description

InvokeID This parameter is locally used and defined by the user to identify the request.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Remote_dlsap_address This parameter contains the destination DLSAP-address in the request and the source
DLSAP-address in the indication.
Destination_dlsap_address This parameter contains the Destination DLSAP-address.
Source_dlsap_address This parameter contains the Source DLSAP-address.
User_data This parameter contains the service dependent body for the APDU.
Result This parameter indicates that the service request succeeded or failed.
Reason_Code This parameter indicates the reason for the Abort.

17.3 State machine

17.3.1 Point-to-point user-Triggered Confirmed client/server ARPM (PTC-ARPM)

17.3.1.1 General

The PTC-ARPM State Machine has two possible states. The defined states and their
descriptions are shown in Table 67 and Figure 15.

Copyright International Electrotechnical Commission

Table 67 – PTC-ARPM states

State Description
CLOSED The AREP is defined, but not capable of sending or receiving FAL-PDUs.
OPEN The AREP is defined and capable of sending or receiving FAL-PDUs.

R1
S3, S4, R2
S1 CLOSED OPEN R3, R4, R5
R6, R7, R8
S2, R11 R9, R10

Figure 15 – State transition diagram of the PTC-ARPM

17.3.1.2 States

The PTC-ARPM state machine is described in Figure 15, and in Table 68 and Table 69.

Table 68 – PTC-ARPM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 CLOSED EST_req CLOSED
=>
Establish_req{
cardinality := “one-to-one”,
remote_confirm := “True”,
sequence_control := “True”
conveyance_policy := “Queue”
}
S2 OPEN ABT_req CLOSED
=>
Abort_req {}
ABT_ind {}
S3 OPEN CS_req OPEN
&& Role = “Client” || “Peer”
=>
FAL-PDU_req {
dlsap_id := DLSAP_ID,
called_address := Destination _dlsap_address,
dlsdu := BuildFAL-PDU (
fal_pdu_name := “CS_PDU”,
fal_data := user_data)
}
S4 OPEN CS_rsp OPEN
&& Role = “Server” || “Peer”
=>
FAL-PDU_req {
dlsap_id := DLSAP_ID,
called_address := Destination _dlsap_address,
dlsdu := BuildFAL-PDU (
fal_pdu_name := “CS_RspPDU”,
fal_data := user_data)
}

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 69 – PTC-ARPM state table – Receiver transitions

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

# Current Event or condition Next state

state
=> action
R1 CLOSED Establish_cnf OPEN
&& status = “Success”
=>
DLSAP_ID := dlsap_id
EST_cnf {
Status := status
}
R2 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) = “CS_ReqPDU”
&& Role = “Peer” || “Server”
=>
CS_ind{
Source _dlsap_address := calling_address,
user _data := fal_pdu
}
R3 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) = “CS_RspPDU”
&& Role = “Client” || “Peer”
=>
CS_cnf{
user_data := fal_pdu
}
R4 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) <> “CS_ReqPDU”
&& Role = “Server”
=>
(no actions taken)
R5 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) <> “CS_RspPDU”
&& Role = “Client”
=>
(no actions taken)
R6 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) <> “CS_ReqPDU”
&& FAL_Pdu_Type (fal_pdu) <> “CS_RspPDU”
&& Role = “Peer”
=>
(no actions taken)
R7 OPEN FAL-PDU_cnf OPEN
&& FALPdu_Type(fal-pdu) = “CS_Req PDU”
&& Role = “Client” || “Peer”
&& status <> “success”
=>
CS_Cnf {
user_data := null,
result := status
}
R8 OPEN FAL-PDU_cnf OPEN
&& Role = “Client” || “Peer”
&& status = “success”
=>
(no actions taken)
R9 OPEN FAL-PDU_Ind OPEN
&& FALPdu_Type(fal-pdu) = “CS_Rsp PDU”
&& Role = “Server” || “Peer”
=>
(no actions taken)
R10 OPEN ErrorToARPM OPEN
=>
(No actions taken. See note.)
R11 OPEN Abort_ind CLOSED
=>
ABT_ind{}

Copyright International Electrotechnical Commission

17.3.2 Point-to-point user-Triggered Unconfirmed client/server ARPM (PTU-ARPM)

17.3.2.1 General

The PTU-ARPM State Machine has two possible states. The defined states and their
descriptions are shown in Table 70 and Figure 16.

Table 70 – PTU-ARPM states

State Description
CLOSED The AREP is defined, but not capable of sending or receiving FAL-PDUs.
OPEN The AREP is defined and capable of sending or receiving FAL-PDUs.

CLOSED OPEN S3, S4, R2

S1
R3, R4, R5
S2, R6

Figure 16 – State transition diagram of the PTU-ARPM

17.3.2.2 State tables

The PTU-ARPM state machine is described in Figure 16, and in Table 71 and Table 72.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Table 71 – PTU-ARPM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 CLOSED EST_req CLOSED
=>
Establish_req{
cardinality := “one-to-one”,
remote_confirm := “True”,
sequence_control := “False”
conveyance_policy := “Queue”
}
S2 OPEN ABT_req CLOSED
=>
Abort_req {}
ABT_ind {}
S3 OPEN UCS_req OPEN
&& Role = “Client” || “Peer”
=>
FAL-PDU_req {
dlsap_id := DLSAP_ID,
called_address := Remote_dlsap_address,
dlsdu := BuildFAL-PDU (
fal_pdu_name := “UCS_PDU”,
fal_data := user_data)
}
S4 OPEN UCS_req OPEN
&& Role = “Server”
=>
(no actions taken)

Copyright International Electrotechnical Commission

Table 72 – PTU-ARPM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 CLOSED Establish_cnf OPEN
&& status = “Success”
=>
DLSAP_ID := dlsap_id
EST_cnf {
Status := status
}
R2 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) = “UCS_PDU”
&& Role = “Server” || “Peer”
=>
CS_ind{
remote_dlsap_address := calling_address,
user_data := fal_pdu
}
R3 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) <> “UCS_PDU”
&& Role = “Client” || “Peer”
=>
(no actions taken)
R4 OPEN FAL-PDU_ind OPEN
&& Role = “Client”
=>
(no actions taken)
R5 OPEN ErrorToARPM OPEN
=>
(No actions taken. See note.)
R6 OPEN Abort_ind CLOSED
=>
ABT_ind{}

17.3.3 Point-to-point network-Scheduled Unconfirmed client/server ARMP (PSU-ARPM)

17.3.3.1 General

The PSU-ARPM State Machine has two possible states. The defined states and their
descriptions are shown in Table 73 and Figure 17.

Table 73 – PSU-ARPM states

State Description

CLOSED The AREP is defined, but not capable of sending or receiving FAL-PDUs.
OPEN The AREP is defined and capable of sending or receiving FAL-PDUs.

CLOSED OPEN S3, S4, S5

S1
R2, R3, R4
S2, R5

Figure 17 – State transition diagram of the PSU-ARPM

17.3.3.2 State tables

The PSU-ARPM state machine is described in Figure 17, and in Table 74 and Table 75.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 74 – PSU-ARPM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 CLOSED EST_req CLOSED
=>
Establish_req{
cardinality := “one-to-one”,
remote_confirm := “False”,
sequence_control := “False”
conveyance_policy := “Buffer”
}
S2 OPEN ABT_req CLOSED
=>
Abort_req {}
ABT_ind {}
S3 OPEN UCS_req OPEN
&& Role =“PushPublisher”
=>
LoadBuffer(Remote_dlsap_address, user_data)
S4 OPEN StartTransmitCycleTimer expired OPEN
&& Role =“PushPublisher”
=>
FAL-PDU_req {
dlsap_id := DLSAP_ID,
called_address := Remote_dlsap_address,,
dlsdu := BuildFAL-PDU (
fal_pdu_name := “UCS_PDU”,
fal_data := local_buf)
},
StartTransmitCycleTimer(arep_id)
S5 OPEN UCS_req OPEN
&& Role = “Subscriber”
=>
(no actions taken)

Table 75 – PSU-ARPM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 CLOSED Establish_cnf OPEN
&& status = “Success”

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
=>
DLSAP_ID := dlsap_id
EST_cnf {}
StartTransmitCycleTimer(arep_id)
R2 OPEN FAL-PDU_ind OPEN
&& Role = “Subscriber”
&& FAL_Pdu_Type (fal_pdu) = “UCS_PDU”
=>
UCS_ind {
remote_dlsap_address := calling_address,
user_data := fal_pdu,
}
R3 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) <> “UCS_PDU”
=>
(no actions taken)
R4 OPEN FAL-PDU_ind OPEN
&& Role = “Publisher”
=>
(no actions taken)
R5 OPEN Abort_ind CLOSED
=>
ABT_ind{}

Copyright International Electrotechnical Commission

17.3.4 Multipoint user-Triggered Unconfirmed publisher/subscriber ARPM (MTU-ARPM)

17.3.4.1 General

The MTU-ARPM State Machine has two possible states. The defined states and their
descriptions are shown in Table 76 and Figure 18.

Table 76 – MTU-ARPM states

State Description

CLOSED The AREP is defined, but not capable of sending or receiving FAL-PDUs.
OPEN The AREP is defined and capable of sending or receiving FAL-PDUs.

CLOSED OPEN S3, S4, R2

S1
R3, R4, R5
S2, R6

Figure 18 – State transition diagram of the MTU-ARPM

17.3.4.2 State tables

The MTU-ARPM state machine is described in Figure 18, and in Table 77 and Table 78.

Table 77 – MTU-ARPM state table – Sender transitions

# Current Event or condition Next state

state => action
S1 CLOSED EST_req CLOSED
=>
Establish_req{
cardinality := “one-to-many”,
remote_confirm := “False”,
sequence_control := “True”
conveyance_policy := “Queue”
}
S2 OPEN ABT_req CLOSED
=>
Abort_req {}
ABT_ind {}
S3 OPEN UCS_req OPEN
&& Role = “Publisher”
=>
FAL-PDU_req {
dlsap_id := DLSAP_ID,
called_address := Remote_dlsap_address,
dlsdu := BuildFAL-PDU (
fal_pdu_name := “UCS_PDU”,
fal_data := user_data)
}
S4 OPEN UCS_req OPEN
&& Role = “Subscriber”
=>
(no actions taken)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 78 – MTU-ARPM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 CLOSED Establish_cnf OPEN
&& status = “Success”
=>
DLSAP_ID := dlsap_id
EST_cnf {}
R2 OPEN FAL-PDU_ind OPEN
&& FAL_Pdu_Type (fal_pdu) = “UCS_PDU”
&& Role = “Subscriber”
=>
CS_ind{
remote_dlsap_address := calling_address,
user_data := fal_pdu
}
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

R3 OPEN FAL-PDU_ind OPEN

&& FAL_Pdu_Type (fal_pdu) <> “UCS_PDU”
=>
(no actions taken)
R4 OPEN FAL-PDU_ind OPEN
&& Role = “Publisher”
=>
(no actions taken)
R5 OPEN ErrorToARPM OPEN
=>
(No actions taken. See note.)
R6 OPEN Abort_ind CLOSED
=>
ABT_ind{}

17.3.5 Multipoint network-Scheduled Unconfirmed publisher/subscriber ARPM (MSU-

ARPM)

17.3.5.1 General

The MSU-ARPM State Machine has two possible states. The defined states and their
descriptions are shown in Table 79 and Figure 19.

Table 79 – MSU-ARPM states

State Description
CLOSED The AREP is defined, but not capable of sending or receiving FAL-PDUs.
OPEN The AREP is defined and capable of sending or receiving FAL-PDUs.

CLOSED OPEN S3, S4, S5

S1
R2, R3, R4
S2, R5

Figure 19 – State transition diagram of the MSU-ARPM

17.3.5.2 State tables

The MSU-ARPM state machine is described in Figure 19, and in Table 80 and Table 81.

Copyright International Electrotechnical Commission

Table 80 – MSU-ARPM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 CLOSED EST_req CLOSED
=>
Establish_req{
cardinality := “one-to-many”,
remote_confirm := “False”,
sequence_control := “False”
conveyance_policy := “Buffer”
}
S2 OPEN ABT_req CLOSED
=>
Abort_req {}
ABT_ind {}
S3 OPEN UCS_req OPEN
&& Role =“Publisher”
=>
LoadBuffer(Remote_dlsap_address, user_data)
S4 OPEN StartTransmitCycleTimer expired OPEN
&& Role =“Publisher”
=>
FAL-PDU_req {
dlsap_id := DLSAP_ID,
called_address := Remote_dlsap_address,,
dlsdu := BuildFAL-PDU (
fal_pdu_name := “UCS_PDU”,
fal_data := local_buf)
},
StartTransmitCycleTimer(arep_id)
S5 OPEN UCS_req OPEN
&& Role = “Subscriber”
=>
(no actions taken)

Table 81 – MSU-ARPM state table – Receiver transitions

# Current Event or condition Next state

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

state
=> action
R1 CLOSED Establish_cnf OPEN
&& status = “Success”
=>
DLSAP_ID := dlsap_id
EST_cnf {}
StartTransmitCycleTimer(arep_id)
R2 OPEN FAL-PDU_ind OPEN
&& Role = “Subscriber”
&& FAL_Pdu_Type (fal_pdu) = “UCS_PDU”
=>
UCS_ind {
remote_dlsap_address := calling_address,
user_data := fal_pdu,
}
R3 OPEN FAL-PDU_ind OPEN
&& || FAL_Pdu_Type (fal_pdu) <> “UCS_PDU”
=>
(no actions taken)
R4 OPEN FAL-PDU_ind OPEN
&& Role = “Publisher”
=>
(no actions taken)
R5 OPEN Abort_ind CLOSED
=>
ABT_ind{}

17.4 Functions

Table 82 lists the functions used by the ARPMs, their arguments, and their descriptions.

Copyright International Electrotechnical Commission

Table 82 – Functions used by the ARPMs

Function name Parameter Description

BuildFAL-PDU fal_pdu_name, This function builds an FAL-PDU out of the parameters given as
fal_data input variables.
FAL_Pdu_Type fal_pdu This function decodes the FAL-PDU that is conveyed in the
dls_user_data parameter and retrieves one of the FALPDU types
LoadBuffer Remote_dlsap_address, This function loads user data into the local buffer.
user_data
StartTransmitCycleTimer arep_id This function starts the timer specified by arep_id.

18 DLL Mapping Protocol Machine (DMPM)

18.1 General

The DLL Mapping Protocol Machine is common to all the AREP types.

The primitives issued by ARPM to DMPM are passed to the Data Link Layer as the DLS
primitives. The primitives issued to DMPM from the Data Link Layer are notified to an
appropriate ARPM out of the ARPMs.

DMPM adds and deletes parameters to/from the primitives exchanged between ARPM and the
Data Link Layer if necessary.

Remarks about DL-identifiers:

The Data Link Layer specification defines two types of identifiers to distinguish each DL
primitive or to match one DL outgoing primitive with the corresponding incoming primitive.
These two identifiers are suffixed as DL-identifier and DLS-user-identifier, respectively. In a
real implementation of an FAL-DL interface, these identifications may be achieved by means
of a pointer to a memory location or a return value of a function call, or something else. For
this reason, these identifiers are not included as parameters of the primitives issued by the
ARPM.

The “DL-identifiers” and “DLS-user-identifiers” are mandatory in the DL-services. The FAL
assumes that the values of these parameters are provided by a local means.

Remark about DLS-user identification:

It is assumed that a connection between one ARPM instance and one DMPM instance is
established locally rather than by means of a protocol. Therefore, DLS-user identification
parameters are not used in the primitives issued by the ARPM.

Remark about buffer or queue identifiers:

The Data Link Layer uses parameters to identify the queue or buffer shared between the Data
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Link Layer and the DLS-user. Although they are useful to clarify the operations of the Data
Link Layer, none of them affects protocol behaviour of the FAL and DL. In a real
implementation, these parameters are implementation-dependent. Therefore, parameters that
correspond directly to these buffer or queue identifiers are not described. A means for
identifying the buffers and queues between the FAL and the DL is a local matter.

Remark about initialization of the Data Link Layer:

The Data Link Layer specification defines services to setup resources within the layer, such
as DL-Create or DL-Bind services. Although they are useful to clarify the operations of the
Data Link Layer, none of them affects protocol behavior of the FAL and DL. Therefore, the
FAL assumes that such initialization procedures have been executed prior to the operations of
the FAL state machines.

Copyright International Electrotechnical Commission

18.2 Primitive definitions

18.2.1 Primitives exchanged between DMPM and ARPM

Table 83 lists the primitives exchanged between the DMPM and the ARPM.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 83 – Primitives exchanged between DMPM and ARPM

Primitive name Source Associated parameters Functions

Establish_req ARPM cardinality, This primitive is used to request establishment of a
remote_confirm, AR.
conveyance_policy,
sequence_control
Abort_req ARPM This primitive is used to request an abort without
transferring an FAL-PDU.
FAL-PDU_req ARPM dlsap_id, This primitive is used to request the DMPM to
called_address, transfer an FAL-PDU. It passes the FAL-PDU to
dll_priority, the DMPM as a DLSDU. It also carries some of
dlsdu the Data Link Layer parameters that are
referenced there.

Establish_cnf DMPM dlsap_id This primitive is used to report completion of the

requested establishment of a AR.
FAL-PDU_ind DMPM calling_address, This primitive is used to pass an FAL-PDU
fal_pdu, received as a Data Link Layer service data unit to
a designated ARPM. It also carries some of the
Data Link Layer parameters that are referenced in
the ARPM.

FAL-PDU_cnf DMPM status

Abort_ind DMPM reason This primitive is used to convey the indication of

abort of provider and its reason.
ErrorToARPM DMPM originator, This primitive is used to convey selected
reason communication errors reported by the Data Link
Layer to a designated ARPM.

18.2.2 Primitives exchanged between Data Link Layer and ARPM

Table 84 lists the primitives exchanged between the Data Link Layer and the ARPM.

Table 84 – Primitives exchanged between Data Link Layer and DMPM

Primitive name Source Associated parameters Functions

DL-U NITDATA _req DMPM dl_called address,
dl_dls_user_data
DL_C REATE _req DMPM Maximum DLSDU size,
Maximum queue depth,
Queue DL-identifier
DL_B IND _req DMPM dl_service_subtype,
dl_dlsap_id
DL-D ELETE _req DMPM Queue DL-identifier

DL-U NBIND _req DMPM DLSAP DL-identifier

DLM-S ET _req DMPM DLM-object-identifier,

Desired-value,
dl_status
DLM-G ET _req DMPM DLM-object-identifier,
Current-value,
Status
DLM-A CTION _req DMPM Desired-action

DL-U NITDATA _ind Data Link Layer dl_calling_address,

dl_dls_user_data
DL-U NITDATA_ cnf Data Link Layer dl_status

DLM-A CTION_ cnf Data Link Layer dl_status

DLM-E VENT _ind Data Link Layer DLM-event-identifier

Copyright International Electrotechnical Commission

18.2.3 Parameters of DMPM/Data Link Layer primitives

The parameters used with the primitives exchanged between the DMPM and the Data Link
Layer are identical to those defined in Section 4 of this PAS. They are prefixed by “dl_” to
indicate that they are used by the FAL.

18.3 DMPM state machine

18.3.1 DMPM states

The DMPM State Machine has only one possible state. The defined state and their
descriptions are shown in Table 85 and Figure 20.

ACTIVE All transitions

Figure 20 – State transition diagram of DMPM

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 85 – DMPM states

State Description

ACTIVE The DMPM in the ACTIVE state is ready to transmit or receive primitives to or from
the Data Link Layer and the ARPM.

18.3.2 DMPM state table

The DMPM state machine is described in Table 86 and Table 87

Table 86 – DMPM state table – Sender transitions

# Current Event or condition Next state

state
=> action
S1 ACTIVE Establish_req ACTIVE
&& cardinality = “one-to-one”
&& remote_confirm = “True”
&& sequence_control := “True”
=>
DL_BIND_req(in){
dl_service_subtype := “ASS”
}

DL_BIND_req(out) -- immediate response

=>
Establish_cnf{
dlsap_id := dl_dlsap_id
}

Copyright International Electrotechnical Commission

# Current Event or condition Next state

state
=> action
S2 ACTIVE Establish_req ACTIVE
&& cardinality = “one-to-one”
&& remote_confirm = “True”
&& sequence_control := “False”
=>
DL_BIND_req(in){
dl_service_subtype := “AUS”
}

DL_BIND_req(out) -- immediate response

=>
Establish_cnf{
dlsap_id := dl_dlsap_id
}
S3 ACTIVE Establish_req ACTIVE
&& cardinality = “one-to-one”
&& remote_confirm = “False”
&& sequence_control := “False”
=>
DL_BIND_req(in){
dl_service_subtype := “UUS”
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

DL_BIND_req(out) -- immediate response

=>
Establish_cnf{
dlsap_id := dl_dlsap_id
}
S4 ACTIVE Establish_req ACTIVE
&& cardinality = “one-to-many”
&& remote_confirm = “False”
&& sequence_control := “False”
=>
DL_BIND_req(in){
dl_service_subtype := “MUS”
}

DL_BIND_req(out) -- immediate response

=>
Establish_cnf{
dlsap_id := dl_dlsap_id
}
S5 ACTIVE Establish_req ACTIVE
&& cardinality = “one-to-many”
&& remote_confirm = “False”
&& sequence_control := “True”
=>
DL_BIND_req(in){
dl_service_subtype := “MSS”
}

DL_BIND_req(out) -- immediate response

=>
Establish_cnf{
dlsap_id := dl_dlsap_id
}
S6 ACTIVE Abort_req ACTIVE
=>
DL-U NBIND _req{},
Abort_ind{}
S7 ACTIVE FAL-PDU_req ACTIVE
=>
PickDlsap (dlsap_id),

DL-U NITDATA _req{

dl_called_address := called_address,
dl_dls_user_data := dlsdu
}

Copyright International Electrotechnical Commission

Table 87 – DMPM state table – Receiver transitions

# Current Event or condition Next state

state
=> action
R1 ACTIVE DL_Unitdata.ind ACTIVE
&& FindAREP (dl_called_address) = “False”
=>
(no actions taken)
R2 ACTIVE DL_Unitdata.ind ACTIVE
&& FindAREP (dl_called_address) = “True”
=>
FAL-PDU_ind {
calling_address := dl_calling_address,
fal_pdu := dl_dls_user_data
}
R3 ACTIVE DL_Unitdata.cnf ACTIVE
&& dl_status <> “success”
=>
ErrorToARPM {
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

originator := “local_dls”,
reason := dl_status
}
FAL-PDU_cnf {
status := dl_status
}
R4 ACTIVE DL_Unitdata.cnf ACTIVE
&& dl_status = “success”
=>
(no actions taken)
FAL-PDU_cnf {
status := dl_status
}

18.3.3 Functions used by DMPM

Table 88 contains the functions used by the DMPM, their arguments and their descriptions.

Table 88 – Functions used by the DMPM

Function name Parameter Description

PickDlsap dlsap_id This function selects the DLSAP specified by the dlsap_id
parameter. After this function is executed, the attributes of the
selected DLSAP is available to the state machine.
FindAREP dl_called_address This function identifies the AREP that shall be bound with an
active DMPM. True means the AREP exists. After this function is
executed, the attributes of the selected AREP are available to the
state machine.

Copyright International Electrotechnical Commission

Section 4: Data Link Service definition

19 Overview

19.1 General

The Data Link Service (DLS) provides transparent and reliable data transfer between DLS-
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

users. It makes the way that supporting communication resources are utilized invisible to
DLS-users.

In particular, the DLS provides the following:

a) Independence from the underlying Physical Layer. The DLS relieves DLS-users from all
direct concerns regarding which configuration is available (for example, direct connection,
or indirect connection through one or more bridges) and which physical facilities are used
(for example, which of a set of diverse physical paths).
b) Transparency of transferred information. The DLS provides the transparent transfer of
DLS-user-data. It does not restrict the content, format or coding of the information, nor
does it ever need to interpret the structure or meaning of that information. It may, however,
restrict the amount of information that can be transferred as an indivisible unit.
c) Reliable data transfer. The DLS relieves the DLS-user from concerns regarding insertion
or corruption of data, or, if requested, loss, duplication or misordering of data, which can
occur. In some cases of unrecovered errors in the Data Link Layer, duplication or loss of
DLSDUs can occur. In cases where protection against misordering of data is not
employed, misordering can occur.
d) Quality of Service (QoS) selection. The DLS provides DLS-users with a means to request
and to agree upon a quality of service for the data transfer. QoS is specified by means of
QoS parameters representing aspects such as mode of operation, transit delay, accuracy,
reliability, security and functional safety.
e) Addressing. The DLS allows the DLS-user to identify itself and to specify the DLSAPs
to/from which data are to be transferred.
f) Scheduling. The DLS allows the set of DLS-users to provide some guidance on internal
scheduling of the distributed DLS-provider. This guidance supports the time-critical
aspects of the DLS, by permitting the DLS-user some degree of management over when
opportunities for communication will be granted to various DLEs for various DLSAP-
addresses.
g) Common time sense. The DLS can provide the DLS-user with a sense of time that is
common to all DLS-users on the network.
h) Queues. The DLS can provide the sending or receiving DLS-user with a FIFO queue,
where each queue item can hold a single DLSDU.

19.2 Overview of network structure

Although the DLS conforms formally to the “three-layer” Fieldbus Reference Model, it actually
utilizes the Transport Layer Service and Network Layer Service in addition to the Data Link
Layer Service of the OSI Basic Reference Model. The DLS of this specification is actually a
Transport Layer Service in terms of the OSI Basic Reference Model. Thus the network may
consist of one or more subnetworks interconnected to each other by the Network Layer Relay
entities, known as routers.

A network may be redundant structure. A redundant network consists of two independent

networks making dual-redundancy; they are referred to as the primary network and secondary
network. Consequently, dual-redundant independent logical communication channels between
two communication end nodes can be implemented. This logical channel is called a route.

Copyright International Electrotechnical Commission

A pair of subnetworks comprising a dual-redundant network is called a domain.

A subnetwork consists of one or more segments interconnected by DL-relay entities, known

as bridges. The topology of a subnetwork may be a tree, a ring or a mesh consisting of
segments interconnected by bridges.

A segment consists of one or more DLEs, all of which are connected directly (i.e., without
intervening DL-relay entities) to a single shared logical communication channel, which is
called a link.

A path (logical communication channel) consists of one or two physically independent and
logically parallel real communication channels, which are called links.

19.3 Overview of addressing

domain number
a numeric identifier that indicates a domain. Two subnetworks comprising a dual-redundant
domain have an identical domain number.

station number
a numeric identifier that indicates a Vnet/IP station. Two end nodes comprising a dual-
redundant station have an identical station number.

TSAP address
the DL-entity actually provides Transport Layer Services, so DLS is provided at TSAPs. TSAP
is identified by a set of TSAP-address (IP-Address) and TSAP-identifier (UDP Port Number).

IP address
a unique address for each end node. An IP address consists of a network address portion and
a host address portion. The network address is assigned according to the domain number,
while the host address is assigned based on the station number. Each end node of a dual-
redundant station has a different host address.

MAC address
MAC address is a unique address for an end node defined in ISO/IEC 8802-3. The destination
MAC address is resolved by the mechanism defined in RFC 826 from the destination IP
address.

19.4 Types of Data Link Service

There are three types of DLS:

a) a DLSAP management service

b) a connectionless-mode data transfer service
c) a DL-management service

20 DLSAP management service

20.1 Overview

This clause provides a conceptual definition of the services provided by the DLS-provider to
the DLS-user(s). Nothing in this section shall be construed to constrain the actual
implementations of the interactions at the DLS-provider to DLS-user interface.

20.2 Facilities of the DLSAP management service

The DLS provides the following facilities to the DLS-user:

a) a means for creating and deleting a FIFO queue of specified depth.

b) a means for assigning a DLSAP-address to the DLSAP.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

c) a means for binding previously created FIFO queues to an each potential direction of
connectionless data transfer at the specified DLSAP.
d) a means for specifying QoS parameters of the specified DLSAP.
e) a means for releasing resources used previously for the DLSAP.

20.3 Model of the DLSAP management service

This part of the PAS uses the abstract model for a layer service defined in ISO/IEC 10731,
Clause 5. The model defines interactions between the DLS-user and the DLS-provider that
take place at a DLSAP. Information is passed between the DLS-user and the DLS-provider by
DLS primitives that convey parameters.

The DLSAP management primitives are used to provide a local service between a DLS-user
and the local DLE. Remote DLEs and remote DLS-users are not involved directly, so there is
no need for the other primitives of ISO/IEC 10731. Therefore the DLSAP management
services are provided by request primitives with input and output parameters.

20.4 Sequence of primitives at one DLSAP

Table 89 is a summary of the DLSAP management primitives and parameters. The major
sequence of primitives at a single DLE is shown in Figure 21.

Table 89 – Summary of DLSAP management primitives and parameters

Service Primitive Parameter

queue creation DL-C REATE request (in Queue DLS-user-identifier,
Maximum DLSDU size,
Maximum queue depth,
out Status,
Queue DL-identifier)
queue deletion DL-D ELETE request (in Queue DL-identifier,
out Status)
DLSAP activation DL-B IND request (in DLSAP-address DLS-user-identifier,
Sending queue DL-identifier
Receiving queue DL-identifier,
QoS parameters,
out Status,
DLSAP-address DL-identifier)
DLSAP deactivation DL-U NBIND request (in DLSAP-address DL-identifier
out Status)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

DL-C REATE request

DL-B IND request

DL-U NITDATA request

or
DL-U NITDATA indication

DL-U NBIND request

DL-D ELETE request

Figure 21 – Sequence of primitives for the DLSAP management DLS

20.5 Create

20.5.1 Function

The create queue DLS primitive may be used to create a limited-depth FIFO queue for later
constrained association with a DLSAP. The resulting FIFO queue initially will be empty.

20.5.2 Types of parameter

Table 90 lists the primitive and parameters of the create queue DLS.

Table 90 – DLSAP-management C REATE primitive and parameters

DL-C REATE Request

Parameter name input output
Queue DLS-user-identifier M
Maximum DLSDU size M
Maximum queue depth M
Status M
Queue DL-identifier C

20.5.2.1 Queue DLS-user-identifier

This parameter specifies a means of referring to the queue in output parameters of other local
DLS primitives that convey the name of the queue from the local DLE to the local DLS-user.

The naming-domain of the queue DLS-user-identifier is the DLS-user’s local-view.

20.5.2.2 Maximum DLSDU size

This parameter specifies an upper bound on the size (in octets) of DLSDUs that can be put
into the queue.

20.5.2.3 Maximum queue depth

This parameter specifies the maximum number of items in the associated queue.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

20.5.2.4 Status

This parameter allows the DLS-user to determine whether the requested DLS was provided
successfully, or failed for the reason specified. The possible value conveyed in this parameter
is as follows:

a) “success”;
b) “failure — insufficient resources”;
c) “failure — parameter violates management constraint”;
d) “failure — number of requests violates management constraint”; or
e) “failure — reason unspecified”.
NOTE Addition to, or refinement of, this list of values, to convey more specific diagnostic and management
information is permitted.

20.5.2.5 Queue DL-identifier

This parameter is present when the Status parameter indicates that the DL-C REATE request
primitive was successful. The queue DL-identifier parameter gives the local DLS-user a
means of referring to the queue in input parameters of other local DLS primitives that convey
the name of the queue from the local DLS-user to the local DLE.

20.6 Delete

20.6.1 Function

The delete queue DLS primitive may be used to delete a queue created by an earlier create
queue DLS primitive.

20.6.2 Types of parameter

Table 91 lists the primitive and parameters of the delete queue DLS.

Table 91 – DLSAP-management D ELETE primitive and parameters

DL-D ELETE Request

Parameter name input output
Queue DL-identifier M
Status M

20.6.2.1 Queue DL-identifier

This parameter specifies the local queue to be deleted. Its value shall be the queue DL-
identifier returned by a successful prior DL-C REATE request primitive. The DLS-provider will
release the local DL-identifier and associated DLS-provider resources.

The DLS-user shall not delete a queue that is still associated with a DLSAP.

20.6.2.2 Status

This parameter allows the DLS-user to determine whether the requested DLS was provided
successfully, or failed for the reason specified. The value conveyed in this parameter is as
follows:

a) “success”;
b) “failure — resource in use”; or
c) “failure — reason unspecified”.
NOTE Addition to, or refinement of, this list of values, to convey more specific diagnostic and management
information is permitted. --``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

20.7 Bind

20.7.1 Function

The bind DLSAP-address DLS primitive is used

a) to associate a DLSAP-address with the DLSAP at which the primitive is invoked;

b) to associate previously created limited depth FIFO queues with the various priorities and
directions of potential data transfer at the specified DLSAP-address; and
c) to specify values for some Quality of Service (QoS) attributes for connectionless data
transfer services using the specified DLSAP-address.

20.7.2 Types of parameter

Table 92 lists the primitive and parameters of the Bind DLSAP-address DLS.

Table 92 – DLSAP management B IND primitive and parameters

DL-B IND Request

Parameter name input output
DLSAP-address DLS-user-identifier M
Sending queue DL-identifier M
Receiving queue DL-identifier M
QoS parameters
DL Service subtype M
DLL maximum confirm delay U
DLL priority U
Authentication level U
Maximum residual error rate U
Transmission Timing Window U
Status M
DLSAP-address DL-identifier C

20.7.2.1 DLSAP-address DLS-user-identifier

This parameter specifies a means of referring to the DLSAP-address in output parameters of

other local DLS primitives that convey the name of the DLSAP-address from the local DLE to
the local DLS-user.

20.7.2.2 Sending queue DL-identifier

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

This parameter specifies the local DL-identifier for sending, which has been returned by a successful
prior DL-CREATE request primitive that created a queue, which has not yet been deleted.

20.7.2.3 Receiving queue DL-identifier

This parameter specifies the local DL-identifier for receiving, which has been returned by a
successful prior DL-C REATE request primitive that created a queue, which has not yet been
deleted.

20.7.2.4 QoS parameters

The DLS-user may specify values for some of the QoS parameters that apply to
connectionless data transmission. If a value is not specified, the default value set by DL-
management is applied for the DLSAP

Copyright International Electrotechnical Commission

20.7.2.5 DL Service subtype

This parameter specifies service subtype of the DLSAP, and the value conveyed in this
parameter is as follows:

a) “UUS” -- Unacknowledged Unitdata transfer Service

b) “AUS” -- Acknowledged Unitdata transfer Service
c) “ASS” -- Acknowledged Sequence of unitdata transfer Service
d) “MUS” – Multipoint Unitdata transfer Service
e) “MSS” – Multipoint Sequence of unitdata transfer Service

The function of each service subtype is specified in clause 3.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

20.7.2.6 DLL maximum confirm delay

This parameter specifies the value of the maximum confirm delay.

20.7.2.7 DLL priority

This parameter specifies the value of the DLL priority.

20.7.2.8 Authentication level

This parameter specifies the level of the DLL authentication.

20.7.2.9 Maximum residual error rate

This parameter specifies a value of the permissible residual error rate.

20.7.2.10 Transmission Timing Window

This parameter specifies the timing window within the macro cycle. It consists of the starting
time in the macro cycle and the time duration when DLE is permitted to transmit DL-U NITDATA
DLPDUs.

20.7.2.11 Status

This parameter allows the DLS-user to determine whether the requested DLS was provided
successfully, or failed for the reason specified. The possible value conveyed in this parameter
is as follows:

a) “success”;
b) “failure — insufficient resources”;
c) “failure — DLSAP-address invalid or unavailable”;
d) “failure — invalid queue binding”;
e) “failure — requested QoS attribute is not available”; or
f) “failure — reason unspecified”.
NOTE Addition to, or refinement of, this list of values, to convey more specific diagnostic and management
information is permitted.

20.7.2.12 DLSAP-address DL-identifier

The DLSAP-address DL-identifier parameter is present when the status parameter indicates
that the DL-B IND request primitive was successful. The DLSAP-address DL-identifier
parameter gives the local DLS-user a means of referring to the DLSAP-address in input
parameters of other local DLS primitives that convey the name of the DLSAP-address from
the local DLS-user to the local DLE.

Copyright International Electrotechnical Commission

The naming-domain of the DLSAP-address DL-identifier is the DL-local-view.

20.8 Unbind

20.8.1 Function

The unbind DLSAP-address DLS primitive is used to unbind a DLSAP-address from the
invoking DLSAP. Any queues that were bound explicitly to the DLSAP-address are also
unbound from that DLSAP-address at the same time.

20.8.2 Types of parameter

Table 93 lists the primitive and parameter of the unbind DLSAP-address DLS.

Table 93 – DLSAP management U NBIND primitive and parameter

DL-U NBIND Request

Parameter name input output
DLSAP-address DL-identifier M
Status M

20.8.2.1 DLSAP-address DL-identifier

This parameter specifies the local DL-identifier returned by a successful prior DL-B IND request
primitive. The DLS-provider shall unbind the local DL-identifier, its associated DLSAP-address,
and any associated queues from the invoking DLSAP, and terminate all outstanding DL-
U NITDATA requests associated with that DLSAP-address.

20.8.2.2 Status

This parameter allows the DLS-user to determine whether the requested DLS was provided
successfully, or failed for the reason specified. The possible value conveyed in this parameter

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
is as follows:

a) “success”;
b) “failure – reason unspecified”.
NOTE Addition to, or refinement of, this list of values, to convey more specific diagnostic and management
information is permitted.

21 Connectionless-mode Data Link Service

21.1 Overview

The DLS provides two types of data transfer services;

a) Point-to-point Data Transfer Services

b) Multipoint Data Transfer Services

There are three types of Point-to-point Data Transfer Services;

a) Unacknowledged Unitdata transfer Service (UUS)

b) Acknowledged Unitdata transfer Service (AUS)
c) Acknowledged Sequence of unitdata transfer Service (ASS)

Copyright International Electrotechnical Commission

There are two types of Multipoint Data Transfer Service;

a) Multipoint Unitdata transfer Service (MUS)

b) Multipoint Sequence of unitdata transfer Service (MSS)

21.2 Facilities of the Connectionless-mode Data Link Service

The DLS provides the following facilities to DLS-user:

a) a means of transferring DLSDUs with limited length from one source DLSAP to a
destination DLSAP or a group of DLSAPs, without establishing or later releasing a Data
Link connection. The transfer of DLSDUs is transparent, which means that the boundaries
of DLSDUs and the contents of DLSDUs are preserved unchanged by the DLS, and there
are no constraints on the DLSDU content (other than limited length) imposed by the DLS
provider. QoS for this transmission may be selected by the sending DLS-user.
b) a means by which the status of delivery to that destination DLSAP can be returned to the
source DLSAP.

21.3 Model of the Data Link Service

21.3.1 General

This clause uses the abstract model for a layer service defined in ISO/IEC 10731, Clause 5.
The model defines local interactions between the DLS-user and the DLS-provider that take
place at a DLSAP. Information is passed between the DLS-user and the DLS-provider by DLS
primitives that convey parameters.

A defining characteristic of Data Link connectionless-mode unitdata transmission is basically

the independent nature of each invocation of the DLS.

21.3.2 DLS-instance identification

A local identification mechanism is provided for each use of the DLS which needs to correlate
a confirmation or subsequent cancellation request with its associated request.

DL-connectionless-mode service primitives may be used to transmit independent DLSDUs

from one DLSAP to another DLSAP or other DLSAPs. Each DLSDU is transmitted in a single
DLPDU. The DLSDU is independent in the sense that it bears no relationship to any other
DLSDU transmitted through an invocation of the DLS. The DLSDU is self-contained in that all
the information required to deliver the DLSDU is presented to the DLS provider, together with
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
the user data to be transmitted, in a single service access.

21.3.3 Unacknowledged Unitdata transfer Service (UUS)

This service permits a local DLS-user to transfer a DLSDU to a single remote end node. The
local DLS-user receives a confirmation acknowledging the completion of the transfer, but not
whether the DLSDU was duly received. At the remote end node this DLSDU is delivered to a
single local DLS-user, if the respective DLPDU is received error-free. There is no confirmation
to the sending DLS-user that such an intended delivery has taken place.

21.3.4 Acknowledged Unitdata transfer Service (AUS)

This service permits the local DLS-user to send a DLSDU to a single remote end node. At the
remote end node, the DLSDU is delivered by the remote DLE to its local DLS-user, if the
respective DLPDU is transferred error-free. The originating local DLS-user receives a
confirmation that indicates whether the DLSDU was received by the remote DLS-user. If an
error occurred during the transfer, the originating DLE retransmits the DLSDU appropriately. If
the specified number of retransmissions fail, a confirmation with error status will be issued to
the local DLS-user.

Copyright International Electrotechnical Commission

21.3.5 Acknowledged Sequence of unitdata transfer Service (ASS)

This service permits the local DLS-user to send a sequence of DLSDUs to a single remote
end node. At the remote end node, the DLSDU are delivered in the original order requested
by the remote DLE to its local DLS-user. The originating local DLS-user receives confirmation
of completion of the transmission of each DLSDU, but does not receive confirmation of receipt
of the DLSDU by the remote DLS-user. If an error occurred during transfer, the originating
DLE retransmits the DLSDUs appropriately. A sequence of DLSDUs is formed from the
requested DLSDUs by originating DLE according to a preconfigured rule.

21.3.6 Multipoint Unitdata transfer Service (MUS)

This service permits a local DLS-user to transfer a DLSDU to the preconfigured group of
remote end nodes at the same time. The local DLS-user receives confirmation of completion
of the transmission, but does not receive confirmation of receipt of the DLSDU by the remote
DLS-user. At each addressed remote end node, this DLSDU is delivered to the remote DLS-
user, if the respective DLPDU is received error-free. There is no confirmation to the sending
DLS-user that such an intended delivery has taken place.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

21.3.7 Multipoint Sequence of unitdata transfer Service (MSS)

This service permits a local DLS-user to transfer a DLSDU to a preconfigured group of remote
end nodes at the same time. The local DLS-user receives confirmation of completion of the
transmission, but does not receive confirmation of receipt of the DLSDU by the remote DLS-
user. At each remote addressed end node, the DLSDU are delivered to the remote DLS-user
in the original requested order.

21.4 Quality of service

A DLS-user may select many aspects of the various Data Link Services. The term “Quality of
Service” (QoS) refers to certain characteristics of a connectionless-mode data transmission
as observed between the DLSAPs. QoS describes aspects of data transmission that are
related solely to the DLS-provider. QoS can only be determined properly when DLS-user
behaviour does not constrain or impede performance of the DLS.

The QoS attributes of the DL-data transfer services apply conceptually to the connectionless
operation. The DLS-user may specify values for these attributes when binding a DLSAP-
address to the DLS-user’s DLSAP; any unspecified attributes will assume the default values
set by DL-management.

21.4.1 Data delivery features

The data delivery feature depends on the type of service, as specified in Table 94.

Table 94 – Data delivery features of each type of service

Service Type Action on Action on Action on Action on

lost DLSDUs duplicated misordered DLSDUs lack of receive buffer
DLSDUs
UUS not detected delivered as delivered as received discarded
received
AUS recovered discarded delivered as received wait & retransmitted
ASS recovered discarded delivered in order wait & retransmitted
conditionally
MUS not detected delivered as delivered as received discarded
received
MSS detected discarded delivered as received discarded

Copyright International Electrotechnical Commission

21.4.2 DLL priority

All connectionless data transfer requests specify an associated DLL priority used in
scheduling DLL data transfer services.

The choice of sending priority implicitly selects the timing characteristics of the DLS provider
execution of the transmission. The following four alternative priorities are available:
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

a) URGENT,
b) HIGH,
c) NORMAL and
d) TIME-AVAILABLE.

The DLSDU requested to transmit with higher priority will be transmitted earlier than those
with lower priority.

21.4.3 DLL maximum confirm delay

Each connectionless service request specifies an upper bound on the maximum time duration
permitted for the completion of each related instance of DLS primitives:

a) the maximum time for completion of a related sequence of locally confirmed DL-U NITDATA
primitives; and
b) the maximum time for completion of a related sequence of remotely confirmed DL-
U NITDATA primitives;

Each parameter has the value UNLIMITED or specifies an upper bound in units of 1 ms, from 1
ms to 60 s inclusive.

21.4.4 Authentication level

This attribute specifies the level of authentication for data transfer. The following four
alternative levels are available:

a) “no authentication”
b) “use 64-bit key code”
c) “use 128-bit key code”
d) “use 256-bit key code”

21.4.5 Maximum residual error rate

This parameter specifies the upper bound on acceptable residual error rate of the underlying
layer service.

The DLL monitors the bit error rate of the underlying layer service continuously. Under
conditions where the residual error rate is higher than the maximum residual error rate, the
requested DL-UNITDATA request is completed with error. The residual error rate is calculated
from the bit error rate and the error detection performance.

This feature allows the DLS-user to switch the sending interface to prevent unexpected loss of
data integrity caused by the underlying service.

21.4.6 Transmission Timing Window

This parameter specifies the timing window within the macro cycle. It consists of the starting
time in the macro cycle and the time duration when DLE is permitted to transmit DL-U NITDATA
DLPDUs.

Copyright International Electrotechnical Commission

21.5 Sequence of primitives

This subclause defines the constraints on the sequence in which the primitives defined may
occur. The constraints determine the order in which primitives occur, but do not fully specify
when they may occur. Other aspects of actual system operation, such as PhL problems
affecting messages in transit, will affect the ability of a DLS-user or a DLS provider to issue a
primitive at any particular time.

The connectionless-mode primitives and their parameters are summarized in Table 95.

Table 95 – Summary of DL-connectionless-mode primitives and parameters

Service Primitive Parameter

Data transfer DL-U NITDATA request (in Called DLSAP-address,
Calling DLSAP-address DL-identifier,
limited DLS-user-data)

DL-U NITDATA indication (out Called DLSAP-address DLS-user-

identifier,
Calling DLSAP-address,
Queue DLS-user-identifier,
limited DLS-user-data)

DL-U NITDATA confirm (out Transfer-Status)

21.5.1 Relation of primitives at the endpoints of connectionless service

A primitive issued at one DLSAP will have consequences at one or more other DLSAPs. The
relations of primitives are summarized in the diagrams of Figure 22.

a) locally-confirmed Unitdata Transfer

DL-
U NITDATA
request DL-U NITDATA
indication

DL-
U NITDATA
confirm

b) remotely-confirmed Unitdata Transfer

DL-
U NITDATA
request DL-U NITDATA
indication

DL-
U NITDATA
confirm

Figure 22 – Summary of DL-connectionless-mode service primitive time-sequence

diagrams

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

21.5.2 Sequence of primitives at one DLSAP

The possible overall sequences of primitives at a DLSAP are defined in the state transition
diagram, Figure 23. The state transition diagram describes the allowable sequences of
service primitives, but does not impose any requirements or constraints on the internal
organization of any implementation of the service.

Idle
1 DL-U NITDATA request,
indication, or confirm

Figure 23 – State transition diagram for sequences of

connectionless-mode primitives at one DLSAP

21.6 Connectionless-mode function

DL-connectionless-mode unitdata transmission service primitives may be used to transmit

independent DLSDUs from one DLSAP to another. Each DLSDU is transmitted in a single
DLPDU. The DLSDU is independent in the sense that it bears no relationship to any other
DLSDU transmitted through an invocation of the DLS. The DLSDU is self-contained in that all
the information required to deliver the DLSDU is presented to the DLS-provider, together with
the user data to be transmitted, in a single service access.

A DLSDU transmitted using DL-connectionless-mode unitdata transmission services is not

considered by the DLS-provider to be related in any way to any other DLSDU. The DLS
maintains the integrity of individual DLSDUs, and delivers them to the receiving DLS-user in
the order in which they are presented by the sending DLS-user if it is determined by the QoS
parameter.

For the remote-confirmed service, the DLS provides the means by which the receiving DLS-
user may control the rate at which the sending DLS-user may send DLSDUs.

21.7 Types of primitives and parameters

Table 96 lists the primitive and parameters of the DL-connectionless-mode U NITDATA transfer
DLS .

Table 96 – DL-connectionless-mode U NITDATA transfer primitives and parameters

DL-U NITDATA Request Indication Confirmation

Parameter name input output output
Called address M
Calling address M
Queue DLS-user-identifier C
DLS-user-data M C(=)
Status M

21.7.1 Called address

This parameter conveys an address identifying the remote DLSAP(s) with which the DLS is to
be provided. It is a DLSAP-address in the request primitive, but takes the form of a local
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

DLSAP-address and DLS-user-identifier in the indication primitive(s). It may be a DLSAP-

address or a group DL-address.

21.7.2 Calling address

This parameter conveys an address of the local DLSAP from which the DLS has been
requested. It is a DLSAP-address in the indication primitive, but takes the form of a local
DLSAP-address and DL-identifier in the request primitive.

21.7.3 Queue DLS-user-identifier

This parameter has the same value as a Queue DLS-user-identifier parameter from prior DL-
C REATE primitive.

21.7.4 DLS-user-data

This parameter allows the data transfer between DLS-users without alteration by the DLS-
provider. The initiating DLS-user may transmit any integral number of octets greater than zero
up to the limit number determined by the Maximum DLSDU size parameter from a prior DL-
C REATE primitive.

21.7.5 Status

This parameter allows the DLS-user to determine whether the requested service was provided
successfully, or failed for the reason specified. The possible value conveyed in this parameter
is as follows:

a) “success”;
b) “failure — sending queue full”;
c) “failure — no requesting DLS-user data specified”;
d) “failure — requested QoS unavailable”;
e) “failure — calling DLSAP DL-identifier is invalid”;
f) “failure — terminated by U NBIND of source DLSAP-address”;
g) “failure — resource limitation in responder”;
h) “failure — fault in responder”;
i) “failure — high bit error rate”;
j) “failure — timeout before transmission”;
k) “failure — timeout after transmission, before acknowledgment”;
l) “failure — sequence number incorrect”; or
m) “failure — reason unspecified”.
NOTE Addition to, or refinement of, this list of values, to convey more specific diagnostic and management
information is permitted.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

22 DL-management Service

22.1 Scope and inheritance

This clause defines the form of DL-management services for protocols that implement the
DLS. Only the form is specified, as the specifics of permitted parameters are dependent on
the protocol that implements these services.

This noteworthy difference between this and the prior clauses is the intended class of users;
this clause is intended for use by a management client, while the prior clauses provide
services to any client.

Copyright International Electrotechnical Commission

22.2 Facilities of the DL-management service

DL-management facilities provide a means for

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

a) writing DLE configuration parameters;

b) reading DLE configuration parameters, operational parameters and statistics;
c) commanding major DLE actions; and
d) receiving notification of significant DLE events.

Together, these facilities constitute the DL-management-service (DLMS).

22.3 Model of the DL-management service

This clause uses the abstract model for a layer service defined in ISO/IEC 10731, Clause 5.
The model defines local interactions between the DLMS-user and the DLMS-provider.
Information is passed between the DLMS-user and the DLMS-provider by DLMS primitives
that convey parameters.

22.4 Constraints on sequence of primitives

The DL-management primitives and their parameters are summarized in Table 97. The only
time-sequence of primitives is shown in Figure 24.

Table 97 – Summary of DL-management primitives and parameters

Service Primitive Parameter

writing managed objects DLM-S ET request (in DLM-object-identifier,
Desired-value,
out Status)
reading managed DLM-G ET request (in DLM-object-identifier,
objects out Status
Current-value)
commanding actions DLM-A CTION request (in Desired-action ,
Action-qualifiers)
DLM-A CTION confirm out Status
Additional-information)
notification of events DLM-E VENT indication (out DLM-event-identifier,
Additional-information)

DLM-Action
request

DLM-Action
confirm

Figure 24 – Sequence of primitives for the DLM action service

22.5 Set

This primitive may be used to set (write) the value of a DLE configuration parameter.

Copyright International Electrotechnical Commission

22.5.1 Types of parameter

Table 98 lists the primitive and parameters of the S ET DLMS.

Table 98 – DLM-S ET primitive and parameters

DLM-S ET Request
Parameter name input output
DLM-object-identifier M
Desired-value M
Status M

22.5.1.1 DLM-object-identifier

This parameter specifies the primitive or composite object within the DLE the value of which is
to be altered. The naming-domain of the DLM-object-identifier is the DLM-local-view.

22.5.1.2 Desired-value

This parameter specifies the desired value for the DLM-object specified by the associated
DLM-object-identifier. Its type is identical to that of the specified DLM-object.

22.5.1.3 Status

This parameter allows the DLMS-user to determine whether the requested DLMS was
provided successfully, or failed for the reason specified. The possible value conveyed in this
parameter is as follows:

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
a) “success”;
b) “failure — DLM-object-identifier is unknown”;
c) “failure — desired-value is not permitted”; or
d) “failure — reason unspecified”.

22.6 Get

22.6.1 Function

This primitive may be used to get (read) the value of a DLE configuration parameter,
operational parameter or statistic.

22.6.2 Types of parameter

Table 99 lists the primitive and parameters of the G ET DLMS.

Table 99 – DLM-G ET primitive and parameters

DLM-G ET Request
Parameter name input output
DLM-object-identifier M
Status M
Current-value C

22.6.2.1 DLM-object-identifier

This parameter specifies the primitive or composite object within the DLE whose value is
being requested. The naming-domain of the DLM-object-identifier is the DLM-local-view.

Copyright International Electrotechnical Commission

22.6.2.2 Status

This parameter allows the DLMS-user to determine whether the requested DLMS was
provided successfully, or failed for the reason specified. The possible value conveyed in this
parameter is as follows:

a) “success”;
b) “failure — DLM-object-identifier is unknown”; or
c) “failure — reason unspecified”.

22.6.2.3 Current-value

This parameter is present when the status parameter indicates that the requested service was
performed successfully. This parameter specifies the current value for the DLM-object
specified by the associated DLM-object-identifier. Its type is identical to that of the specified
DLM-object.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
22.7 Action

22.7.1 Function

This primitive may be used to command a specified action of the DLE.

22.7.2 Types of parameter

Table 100 lists the primitive and parameters of the A CTION DLMS.

Table 100 – DLM-A CTION primitive and parameters

DLM-A CTION Request Confirm

Parameter name input output
Desired-action M
Action-qualifiers C
Status M
Additional-information C

22.7.2.1 Desired-action

This parameter specifies the desired action that the DLE is to take.

22.7.2.2 Action-qualifiers

This optional parameter specifies additional action-specific parameters that serve to qualify
the commanded action.

22.7.2.3 Status

This parameter allows the DLMS-user to determine whether the requested DLMS was
provided successfully, or failed for the reason specified. The possible value conveyed in this
parameter is as follows:

a) “success”;
b) “failure — action is unknown”;
c) “failure — action is not permitted in current DLE state”;
d) “failure — action did not complete”; or
e) “failure — reason unspecified”.

Copyright International Electrotechnical Commission

22.7.2.4 Additional-information

This optional parameter provides action-specific additional information that augments the
returned status.

22.8 Event

22.8.1 Function

This primitive is used to report the occurrence of a significant DL-event for DL-management.

22.8.2 Types of parameter

Table 101 lists the primitive and parameters of the E VENT DLMS.

Table 101 – DLM-E VENT primitive and parameters

DLM-E VENT Indication

Parameter name output
DLM-event-identifier M

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Additional-information C

22.8.2.1 DLM-event-identifier

This parameter specifies the primitive or composite event within the DLE the occurrence of
which is being announced. The naming-domain of the DLM-event-identifier is the DLM-local-
view.

22.8.2.1.1 Additional-information

This optional parameter provides event-specific additional information.

Copyright International Electrotechnical Commission

Part 5: Data Link protocol specification

23 Overview of the DL-protocol

23.1 General

The Vnet/IP Data Link Layer provides basic real-time and reliable communications between
devices in automation environments.

This part of the document specifies:

a) procedures of the Data Link (DL) protocols for real-time data transfer and control
information from one Data Link Service user entity to a peer user entity, and among the

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Data Link entities forming the distributed Data Link Service provider.
b) the structure of the Data Link Protocol Data Units (DLPDUs) used for data transfer and
control information, and their mapping to the underlying layers.

The procedures are defined in terms of:

a) the interactions between peer DL-entities (DLEs) through the exchange of fieldbus Data
Link Protocol Data Units.
b) the interactions between a DL-service (DLS) provider and a DLS-user in the same system
through the exchange of DLS primitives.
c) the interactions between a DLS-provider and a Physical Service provider in the same
system through the exchange of Ph-service primitives.

23.2 Characteristics of the protocol

The requirements of continuous process control, e.g. in the Oil & Gas, Petrochemical &
Chemical, Pharmaceutical and Power industries, result in the following characteristic features
of the Vnet/IP Data Link protocol.

The maximum system size for this protocol is 254 subnetworks of 254 nodes, where each
node has 254 DLSAP-addresses. All Data Link entities can communicate with all others in a
cyclic or acyclic manner with prioritized access, or in a combination of the two.

This protocol provides real-time communication by means of transmission scheduling. The

minimum cycle-time of scheduling is 10 ms. In addition, it provides a means to maintain clock
synchronization across a subnetwork with a precision better than 1 ms, and across an
extended network with a precision better than 5 ms.

This protocol provides reliable and flexible communications by remotely confirmed acyclic data
transfer with retransmission. In addition, it provides a dual-redundant network with a switchover
time of less than 100 ms, and also provides the facilities for dual-redundant devices.

23.3 Data Link Layer architecture

23.3.1 General

The DLL is modeled as:

a) a real-time data transfer function

b) a datagram transfer function
c) a network routing function
d) a media access function
e) a logical link and management function

Copyright International Electrotechnical Commission

With the exception of the real-time data transfer function, each function is implemented
according to the following existing protocols specified in Table 102.

Table 102 – Referenced standards for the layers

Function Compliance
Datagram transfer function RFC 768 (UDP)
Network routing function RFC 791 (IP)
Media access function ISO/IEC 8802-3

23.3.2 Real-time data transfer function

The real-time data transfer function is specified in this specification, and it provides the
Connectionless-mode Data Link Service specified in Section 4 of this PAS.

23.3.3 Datagram transfer function

The datagram transfer function is compliant with RFC 768 (UDP definition), and provides
datagram transfer service for the real-time data transfer function.

23.3.4 Network routing function

The network routing function is compliant with RFC 791 (IP definition), and provides datagram
routing service for the datagram transfer function.

This function also performs fragmentation of a datagram to maintain independence from MTU
of the underlying sublayer. The function utilizes two logical link functions to realize a dual-
redundant network.

In a dual-redundant station, two network routing entities are implemented for both end nodes.

23.3.5 Logical link and media access function

The logical link and media access function is compliant with ISO/IEC 8802-3. It provides
fragments transfer service within a subnetwork and a means of accessing the network for the
network routing function.

Two entities that execute media access function are implemented in a node to realize a dual-
redundant network.

23.3.6 Management function

The management function is specified in this specification, and it provides the DL-
management Service and DLSAP management Data Link Service. These services are
specified in Section 4 of this PAS.

23.4 Services provided by the DLL

23.4.1 General
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

The services provided by the DLL are specified in Section 4 of this PAS.

There are three types of Data Link Service:

a) a Connectionless-mode Data Link Service

b) a DLSAP management Data Link Service
c) a DL-management Service
Copyright International Electrotechnical Commission
Provided by IHS under license with IEC Licensee=Daewoo Corporation/5908861001
No reproduction or networking permitted without license from IHS Not for Resale, 06/13/2006 23:28:47 MDT
– 132 – PAS 62405 © IEC:2005(E)

23.4.2 Quality of Service (QoS) attributes

QoS attributes specified by the DLS-user select some aspects of the various Data Link
Services, and can be specified only when a DLSAP-address is bound to the DLS-user’s
DLSAP.

23.4.2.1 Service subtype

This attribute determines a service subtype of data transfer service of DLSAP specified by
DL-B IND request.

Each service subtype has different data delivery features and different data transfer
relationships i.e., the point-to-point or multipoint model. Some QoS attributes are limited by
the type of service subtype.

There are five service subtypes:

a) Unacknowledged Unitdata transfer Service (UUS)

b) Acknowledged Unitdata transfer Service (AUS)
c) Acknowledged Sequence of unitdata transfer Service (ASS)
d) Multipoint Unitdata transfer Service (MUS)
e) Multipoint Sequence of unitdata transfer Service (MSS)

23.4.2.2 DLL maximum confirm delay

This attribute determines the upper bound on the time delay permitted until the DL-U NITDATA
service is confirmed, i.e., the maximum permissible delay between the issuing of a DL-
U NITDATA request primitive and receiving of the corresponding DL-U NITDATA confirm primitive.

The parameter specifies an interval from 1 ms to 60 s inclusive in units of 1 ms.

23.4.2.3 DLL priority

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

This attribute specifies an associated DLL priority used in scheduling DLL data transfer
services. The DL-protocol should support four DLL priority levels. The four DLL priorities, from
highest to lowest priority, are as follows:

a) URGENT
b) HIGH
c) NORMAL
d) TIME-AVAILABLE

The priority attribute assigned for each DLSDU is recognized by both of the sending DLE and
receiving DLE, and it may be translated to the underlying service QoS parameter which is
used by lower entities to control the priority of PDU transfer.

In the sending DLE, DLSDU with higher priority requested by a DL-U NITDATA request primitive
is transmitted in advance of any other DLSDUs with lower priority.

In the receiving DLE, the received DLPUD with higher priority is delivered to the DLS-user in
advance of any other DLPDUs with lower priority.

23.4.2.4 Maximum DLSDU size

The DLS-user data requested by DL-U NITDATA request are conveyed in a single DLPDU. The
Maximum DLSDU size attribute specifies an upper bound on the size (in octets) of DLSDUs

Copyright International Electrotechnical Commission

that will be offered for transmission, and an upper bound on the size of DLSDUs that are
acceptable for reception.

The parameter shall be chosen from 256 × N, where 1 ≤ N ≤ 16.

NOTE The maximum size of DLSDU supported for DLSAP, which is assigned as Acknowledged Unitdata transfer
Service (AUS) for service subtype, is limited to 2048.

23.4.2.5 Authentication level

This attribute specifies the level of authentication for data transfer. The following four
alternative levels are available:

a) “no authentication”
b) “use 64-bit key code”
c) “use 128-bit key code”
d) “use 256-bit key code”

23.4.2.6 Maximum residual error rate

This parameter specifies upper bound on acceptable residual error rate of the underlying layer
service.

The DLL monitors the bit error rate of the underlying layer service continuously. Under
conditions where the residual error rate, calculated from the bit error rate and the error
detection performance, is higher than the maximum residual error rate, the requested DL-
U NITDATA request is completed with error.

This feature supports the DLS-user switching the sending interface to prevent unexpected
loss of data integrity caused by the underlying service.

23.5 Network sharing with other protocols

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
Other TCP-based protocols, such as HTTP and FTP, can work on the same network alongside
communication of the DLE. In this case, total traffic of communication based on other
protocols shall be limited by some means such as switching hubs. The methods for limitation
are outside the scope of this specification.

24 DLPDU-parameter structure and encoding

24.1 Overview

The specification of the transfer syntax combines the specification of the abstract syntax and
their encodings as a set of fixed-format DLPDUs. Each DLPDU contains a DLPDU common
header and a DLPDU body.

The DLPDU body consists of an individual header, which is specified by the service subtype,
and the DLSDU.

24.1.1 Data type encodings

The following data types, which are specified in Part 3 of this document, are used in DLPDU
definitions.

a) Unsigned8
b) Unsigned16
c) Unsigned32

Copyright International Electrotechnical Commission

d) OctetString

The bit positions in an octet value are defined in Table 103.

Table 103 – Bit Positions

Bit Position Hex Value Decimal Value

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
8 0x80 128
7 0x40 64
6 0x20 32
5 0x10 16
4 0x08 8
3 0x04 4
2 0x02 2
1 0x01 1

24.1.2 Structure and definition of DL-addresses

Although the DLS conforms formally to the “three-layer” Fieldbus Reference Model, it actually
utilizes the Network Layer Service of the OSI Basic Reference Model and IP address
specified by RFC 791.

The IP unicast and multicast addresses shall be used as the DL-address.

24.2 DLPDU common header format

Table 104 defines the common header format.

Copyright International Electrotechnical Commission

Table 104 – Common Header format

Parameter Octet Data type Octet Description

name offset length
DLPUD Version 0 Unsigned8 1 Specifies the Version number of the DLPDU format.
The version number of the DLPDUs specified in this
PAS is 1
1 = Version 1
PDU type 1 Unsigned8 1 Indicates DLPDU attribute
Bit 8: 1= Multicast
Bit 7: 1= For external of the domain
Bit 6: 1= Response
Bit 5: 1= Remote confirmation is requested
Bits 4-3: Indicates destination SAP-ID
0= DLS-user (SAP)
1= DL Management
2= Reserved
3= Reserved
Bits 2-1: Indicates destination extension
0= Don’t care
1= On-service end node
2= Standby end node
3= Both
Service Subtype 2 Unsigned8 1 Indicates the subtype of service
Bits 8-5:
1= UUS
2= AUS
3= ASS
4= MUS
5= MSS
All other values are reserved
Bits 4-1: reserved
Option 3 Unsigned8 1 Indicates the options
Bits 8-5: indicates security option
0= No security control

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
1= 2 octet authentication data, simplified control
2= 2 octet authentication data, full control
3= 4 octet authentication data, simplified control
4= 4 octet authentication data, full control
All other values are reserved
Bits 4-1: indicate safety option
0= No safety control
All other values are reserved.
Total Length 4 Unsigned32 4 Indicates octet length of the DLPDU
Authentication 8 Unsigned n Authentication data created according to the security
Data type
The length is specified by the security option.
Integrity Data 8+n Unsigned m Authentication data created according to the security
type
The length is specified by the safety option.

24.3 DLPDU body format

There are 8 kinds of DLPDU. Table 105 is the list of DLPDUs.

Table 105 – DLPDU Types

DLPDU name Description

UUS_DT_PDU This PDU conveys DLSDU of UUS service.
AUS_DT_PDU This PDU conveys DLSDU of AUS service.
AUS_RSP_PDU This PDU is used to respond to the AUS_DATA_PDU.
ASS_DT_PDU This PDU conveys DLSDU of AAS service.
ASS_ENQ_PDU This PDU is used to enquire whether ASS_DTPDUs are received.
ASS_RSP_PDU This PDU is used to respond to the ASS_ENQ_PDU.
MUS_DT_PDU This PDU conveys DLSDU of MUS service.
MSS_DT_PDU This PDU conveys DLSDU of MSS service.

Copyright International Electrotechnical Commission

Table 106 defines assignment of the Service Subtype and PDU type field of the common
header for each DLPDU.

Table 106 – Service subtype and PDU type of DLPDUs

DLPDU Service PDU type

Type Subtype Multicast External Response Confirm SAP-ID Extension
UUS_DATA 1 0 0/1 0 0 DEPND DEPND
AUS_DATA 2 0 0 0 1 DEPND DEPND
AUS_RSP 2 0 0 1 0 DEPND DEPND
ASS_DATA 3 0 0/1 0 0 DEPND DEPND
ASS_ENQ 3 0 0/1 0 1 DEPND DEPND
ASS_RSP 3 0 0/1 1 0 DEPND DEPND
MUS_DATA 4 1 0/1 0 0 DEPND DEPND
MSS_DATA 5 1 1/1 0 0 DEPND DEPND

24.3.1 Common parameter of DLPDU body

The common parameters are defined as follows.

Service Subtype
This parameter is the same as Service Subtype in the common header.

PDU subtype
This parameter specifies the subtype that represents the role of the DLPDU.

Status
This parameter indicates the status of the transaction.

Sequence number
This parameter identifies the DT_PDU, and is also used to inform the latest received DT_PDU
in the RSP_PDUs.

DLSAP ID
This parameter indicates the DLSAP identifier.

DLSDU length
This parameter indicates the octet length of the DLSDU.

DLSDU
This parameter is the user data requested by the Unitdata request.

24.3.2 DLPDU format for UUS

Table 107 indicates the body format of DLPDU for UUS.

Table 107 – UUS_DT_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 1 (UUS)
Bits 4-1: reserved
PDU Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 1 = DATA
Bits 4-1: reserved
Status 2 Unsigned8 1 Not Used, set to 0
Sequence number 3 Unsigned8 1 Identifies PDU in the sequence of PDUs
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Indicates octet length of the DLSDU
DLSDU 8 OctetString - DLSDU requested by DLS-user
The length of DLSDU is specified by the
DLSDU length

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

24.3.3 DLPDU format for AUS

Table 108 and Table 109 indicate body formats of DLPDU for AUS.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 108 – AUS_DT_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 2 (AUS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 1 = DATA
Bits 4-1: reserved
Status 2 Unsigned8 1 Indicates status of the transaction
Bits 8-5: reserved
Bits 4-1: Retry count
Sequence number 3 Unsigned8 1 Identifies PDU in the sequence of PDUs
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Indicates octet length of the DLSDU
DLSDU 8 OctetString - DLSDU requested by DLS-user
The length of DLSDU is specified by the
DLSDU length

Table 109 – AUS_RSP_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 2 (AUS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 8 = RESPONE
Bits 4-1: reserved
Status 2 Unsigned8 1 Indicates the status of response
0= Normal
1= reserved
2= Buffer busy
3= Sequence error
Sequence number 3 Unsigned8 1 Identifies Sequence number expected for
next DT_PDU
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Always set to 0

24.3.4 DLPDU format for ASS

Table 110, Table 111 and Table 112 indicate body formats of DLPDU for ASS.

Copyright International Electrotechnical Commission

Table 110 – ASS_DT_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 3 (ASS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 1 = DATA
Bits 4-1: reserved
Status 2 Unsigned8 1 Indicates status of the transaction
Bit 8: 1= Initial PDU of sequence
Bits 4-1: Retry count
All other bits are reserved
Sequence number 3 Unsigned8 1 Identifies PDU in the sequence of PDUs
It is managed for each remote IP address
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Indicates octet length of the DLSDU
DLSDU 8 OctetString - DLSDU requested by DLS-user
The length of DLSDU is specified by the
DLSDU length

Table 111 – ASS_ENQ_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 3 (ASS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 4 = ENQ
Bits 4-1: reserved
Status 2 Unsigned8 1 Indicates status of the transaction
Bits 4-1: Retry count
All other bits are reserved
Sequence number 3 Unsigned8 1 Identifies the expected sequence number in
the response PDUs
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Always set to 0

Table 112 – ASS_RSP_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 3 (ASS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Bits 8-5: 8 = RESPONSE

Bits 4-1: reserved
Status 2 Unsigned8 1 Indicates the status of response
0= Normal
1= reserved
2= Buffer busy
3= Sequence error
Sequence number 3 Unsigned8 1 Identifies Sequence number expected for
next DT_PDU
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Always set to 0

24.3.5 DLPDU format for MUS

Table 113 indicates the body format of DLPDU for MUS.

Copyright International Electrotechnical Commission

Table 113 – MUS_DT_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 4 (MUS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 1 = DATA
Bits 4-1: reserved
Status 2 Unsigned8 1 Indicates DLSAP identifier
Sequence number 3 Unsigned8 1 Identifies PDU in the sequence of PDUs
DLSAP ID 4 Unsigned16 2 Not Used, set to 0
DLSDU Length 6 Unsigned16 2 Indicates octet length of the DLSDU
DLSDU 8 OctetString - DLSDU requested by DLS-user
The length of DLSDU is specified by the
DLSDU length

24.3.6 DLPDU format for MSS

Table 114 indicates the body format of DLPDU for MSS.

Table 114 – MSS_DT_PDU

Parameter name Octet Data type Octet Description

offset length
Service subtype 0 Unsigned8 1 Same as service subtype in common header
Bits 8-5: 5 (MSS)
Bits 4-1: reserved
Subtype 1 Unsigned8 1 Indicates the subtype of DLPDU
Bits 8-5: 1 = DATA
Bits 4-1: reserved
Status 2 Unsigned8 1 Not Used, set to 0
Sequence number 3 Unsigned8 1 Identifies PDU in the sequence of PDUs
DLSAP ID 4 Unsigned16 2 Indicates DLSAP identifier
DLSDU Length 6 Unsigned16 2 Indicates octet length of the DLSDU
DLSDU 8 OctetString - DLSDU requested by DLS-user
The length of DLSDU is specified by the
DLSDU length

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
25 Local parameters and resources

25.1 General

The Data Link Layer uses the following local parameters and resources:

a) system parameters P(…)

b) local variables V(…)
c) local timers T(…)
d) local counters C(…)

Unless otherwise specified, at the moment of creation of these resources or of DLE activation:

a) all variables shall be initialized to their default value, or to their minimum permitted value
if no default is specified;
b) all counters shall be initialized to zero;
c) all timers shall be initialized to inactive.

DL-management may change the values of configuration variables.

Copyright International Electrotechnical Commission

The following data types which are specified in Section 3 of this PAS ment are used in the
definitions of parameters and resources.

a) Boolean
b) Integer
c) BinaryTime2 (1 ms resolution)
d) BinaryTime5 (1 s resolution)
e) IPaddress

25.2 Parameters and resources related to network structure

Table 115 lists the parameters and resources related to the network structure.

Table 115 – Parameters and resources for the network structure

SYNBOL NAME DESCRIPTIONS

P(ND) max-domains Maximum number of domains
P(HC) max-hop-count Maximum hop-count of the network
P(NS) max-stations Maximum number of stations in a domain
P(GA 1A ) IP-group-address-1A IP-group-address of the multicast to all nodes in the domain for
interface A

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
P(GA 1B ) IP-group-address-1B IP-group-address of the multicast to all nodes in the domain for
interface B
P(GA 2A ) IP-group-address-2A IP-group-address of the multicast to all nodes of the network for
interface A
P(GA 2B ) IP-group-address-2B IP-group-address of the multicast to all nodes of the network for
interface B
P(AB DA ) IP-base-address-domain-A Base subnet-address of domains for interface A
P(AB DB ) IP-base-address-domain-B Base subnet-address of domains for interface B
V(TD) this-domain Domain number of this domain
The possible range of values is 1 to P(ND)
V(TS) this-station Station number of this station
The possible range of values is 1 to P(NS)
V(RID) redundant-node-ID End node Identifier of the redundant station
Possible values are “0” and “1”
V(IP A ) IP-address-A IP-address for interface A
This variable is assigned according to the P(TD), P(AB DA ), P(TS) and
P(RID)
V(IP A ) = P(AB DA ) + P(TD) + P(TS) x2 + P(RID)
V(IP B ) IP-address-B IP-address for interface B
This variable is assigned according to the P(TD), P(AB DB ), P(TS) and
P(RID)
V(IP B ) = P(AB DB ) + P(TD) + P(TS) x2 + P(RID)

Table 116 defines the permissible ranges of the parameters.

Copyright International Electrotechnical Commission

Table 116 – Ranges of parameters for the network structure

PARAMTER DATA TYPE RANGE

P(ND) Integer 1 to 254
P(HC) Integer 1 to 16
P(NS) Integer 1 to 254
P(GA 1A ) IPaddress any IPv4 group address
P(GA 1B ) IPaddress any IPv4 group address
P(GA 2A ) IPaddress any IPv4 group address
P(GA 2B ) IPaddress any IPv4 group address
P(AB DA ) IPaddress any IPv4 Class C unicast address
P(AB DB ) IPaddress any IPv4 Class C unicast address

25.3 Parameters and resources to support real-time data transfer

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Table 117 lists the parameters and resources used to support real-time data transfer.

Table 117 – Parameters and resources real-time data transfer

SYNBOL NAME DESCRIPTIONS

P(MRC AUS ) max-retry-count-AUS Maximum retry count for AU
P(MRC ASS ) max-retry-count-ASS Maximum retry count for ASS
P(MOS) max-outstanding-number Maximum outstanding number of PDUs for ASS before the
ENQ_PDU
P(TNR AUS ) max-response-time-AUS Expiration time of no-response-timer for AUS
P(TNR ASS ) max-response-time-ASS Expiration time of no-response-timer for ASS
P(TWT AUS ) wait-time-AUS Wait time between receiving of RSP_PDU with buffer busy status
and successive retransmission of DT_PDU for AUS
P(TWT ASS ) wait-time-ASS Wait time between receiving of RSP_PDU with buffer busy status
and successive retransmission of ENQ_PDU for ASS
P(TID ASS ) inter-DTPDU-time Interval time value between last ASS_DT_PDU and ENQ_PDU
C(RT AUS ) transfer-retry counter This counter counts number of retries
C(RT ASS ) transfer-retry counter This counter counts number of retries
C(OS) outstanding-counter This counter counts number of ASS_DT_PDU before ENQ_PDU.
T(NR AUS ) no-response-timer This timer is used to monitor the RSP_PDU
T(NR ASS ) no-response-timer This timer is used to monitor the RSP_PDU
T(ID ASS ) inter-DTPDU-timer This timer is used to monitor the interval between two successive
ASS_DT_PDUs
V(SQ SND ) PDU-sequence-number- This variable is local to the sequence number that is used for the
sending next DT_PDU
V(SQ RCV ) PDU-sequence-number- This variable is local to the sequence number of the latest DT_PDU
received received

Table 118 defines the permissible ranges of the parameters.

Table 118 – Ranges of parameters for real-time data transfer

PARAMTER DATA TYPE RANGE

P(MRC AUS ) Integer 0 or an odd number out from 1 to 15
P(MRC ASS ) Integer 0 or an odd number out from 1 to 15
P(MOS) Integer 1 to 255
P(TNR AUS ) BinaryTime2 1 to 255 ms
P(TNR ASS ) BinaryTime2 1 to 255 ms
P(TWT AUS ) BinaryTime2 1 to 255 ms
P(TWT ASS ) BinaryTime2 1 to 255 ms
P(TID ASS ) BinaryTime2 10 to 2047 ms

Copyright International Electrotechnical Commission

25.4 Parameters and resources to support the scheduling function

Table 119 lists the parameters and resources used to support the scheduling function.

Table 119 – Parameters and resources for scheduling function

SYNBOL NAME DESCRIPTIONS

P(MC) macro-cycle-period Time period of a macro cycle
P(SD UUS ) starting-delay-UUS List of starting delay time of UUS slots
P(SD AUS ) starting-delay-AUS List of starting delay time of AUS slots
P(SD ASS ) starting-delay-ASS List of starting delay time of ASS slots
P(SD MUS ) starting-delay-MUS List of starting delay time of MUS slots
P(SD MSS ) starting-delay-MSS List of starting delay time of MSS slots
P(TD UUS ) time-duration-UUS Time duration UUS slot
P(TD AUS ) time-duration-AUS Time duration AUS slot
P(TD ASS ) time-duration-ASS Time duration ASS slot
P(TD MUS ) time-duration-MUS Time duration MUS slot
P(TD MSS ) time-duration-MSS Time duration MSS slot
P(TO UUS ) offset-time-UUS Offset time of UUS slot
P(TO AUS ) offset-time-AUS Offset time of AUS slot
P(TO ASS ) offset-time-ASS Offset time of ASS slot
P(TO MUS ) offset-time-MUS Offset time of MUS slot
P(TO MSS ) offset-time-MSS Offset time of MSS slot
P(DV UUS ) divisor-for-grouping Divisor value of modulo for the offset grouping of UUS
P(DV AUS ) divisor-for-grouping Divisor value of modulo for the offset grouping of AUS
P(DV ASS ) divisor-for-grouping Divisor value of modulo for the offset grouping of ASS
P(DV MUS ) divisor-for-grouping Divisor value of modulo for the offset grouping of MUS
P(DV MSS ) divisor-for-grouping Divisor value of modulo for the offset grouping of MSS
T(SCH) scheduling-timer This timer is used to recognize each slot.

Table 120 defines the permissible ranges of the parameters.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 120 – Ranges of parameters for scheduling

PARAMTER DATA TYPE RANGE

P(MC) BinaryTime2 10 ms to 1000ms
P(SD UUS ) Array of BinaryTime2 Each value is in the range from 0 ms to P(MC)
P(SD AUS ) Array of BinaryTime2 Each value is in the range from 0 ms to P(MC)
P(SD ASS ) Array of BinaryTime2 Each value is in the range from 0 ms to P(MC)
P(SD MUS ) Array of BinaryTime2 Each value is in the range from 0 ms to P(MC)
P(SD MSS ) Array of BinaryTime2 Each value is in the range from 0 ms to P(MC)
P(TD UUS ) BinaryTime2 1 ms to (P(MC) – 1 ms)

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
P(TD AUS ) BinaryTime2 1 ms to (P(MC) – 1 ms)
P(TD ASS ) BinaryTime2 1 ms to (P(MC) – 1 ms)
P(TD MUS ) BinaryTime2 1 ms to (P(MC) – 1 ms)
P(TD MSS ) BinaryTime2 1 ms to (P(MC) – 1 ms)
P(TO UUS ) BinaryTime2 0 ms to P(TD UUS )
P(TO AUS ) BinaryTime2 0 ms to P(TD AUS )
P(TO ASS ) BinaryTime2 0 ms to P(TD ASS )
P(TO MUS ) BinaryTime2 0 ms to P(TD MUS )
P(TO MSS ) BinaryTime2 0 ms to P(TD MSS )
P(DV UUS ) Integer 1 to 255
P(DV AUS ) Integer 1 to 255
P(DV ASS ) Integer 1 to 255
P(DV MUS ) Integer 1 to 255
P(DV MSS ) Integer 1 to 255

25.5 Parameters and resources to support the security function

Table 121 lists the parameters and resources used to support the security function.

Table 121 – Parameters and resources for security function

SYNBOL NAME DESCRIPTIONS

P(KS) key size Size of the keys in octet
P(AS) authentication field size Size of the authentication field in octet
P(PN) prime-number Prime number for the key generation
P(BS) base-number Base number for the key generation
P(UD) key-update-time Time period over which the key is updated
T(UD) key-update-timer This timer generates update timing of the key

Table 122 lists the permissible ranges of the parameters.

Table 122 – Ranges of parameters for security function

PARAMTER DATA TYPE RANGE

P(KS) Integer 1,2,4,8,16
P(AS) Integer 1,2,4,8,16,32,64
P(PN) Integer 0 to P(KS)
P(BS) Integer 0 to P(PN)
P(UD) BinaryTime5 1 to 3600 s

Copyright International Electrotechnical Commission

26 DL-service elements of procedure

26.1 Unacknowledged Unitdata transfer Service (UUS)

The procedure of UUS is described in Table 123.

Table 123 – UUS Procedure

Event Condition Procedure

DL-UNITDATA 1) Selects a transmit interface and a destination IP
request address, according to the network status table
2) Transmits UUS_DT_PDU with V(SQ SND )
3) Issues a DL- UNITDATA confirm
Receiving DT_PDU seqNo <> V(SQ RCV ) 1) Issues a DL-UNITDATA indication primitive at the
DLSAP with DLSDU
2) Updates V(SQ RCV )
seqNo = V(SQ RCV ) 1) No action taken

26.2 Acknowledged Unitdata transfer Service (AUS)

The procedure of AUS is described in Table 124.

Table 124 – AUS Procedure

Event Condition Procedure

DL-UNITDATA 1) Transmits AUS_DT_PDU for the destination
request 2) Starts T(NR)
Receive RSP_PDU Expected RSP_PDU 1) Issues a DL- UNITDATA confirm with DLSDU
&& status = “normal”
Expected RSP_PDU 1) wait P(TWT AUS )
&& status = “buffer busy” 2) Retransmits DT_PDU
&& C(RT AUS ) < P(MRC AUS ) 3) Increments C(RT AUS )
Expected RSP_PDU 1) Issues a DL-UNITDATA confirm with error status
&& status = “buffer busy”
&& C(RT AUS ) = P(MRC AUS )
T(NR AUS ) = P(TNR AUS ) C(RT AUS ) < P(MRC AUS ) 1) Updates network status table accordingly
2) Selects a transmit interface and a destination IP
address, accordingly
3) Retransmits AUS_DT_PDU
C(RT AUS ) = P(MRC AUS ) 1) Issues a DL- UNITDATA confirm with error status
Receive DT_PDU seqNo <> V(SQ RCV ) 1) Issues a DL-UNITDATA indication primitive at the
&& buffer is available DLSAP with DLSDU
2) Updates V(SQ RCV )
3) Transmits RSP_PDU
seqNo <> V(SQ RCV ) 1) Transmits RSP_PDU with “buffer busy” status
&& buffer is not available
seqNo = V(SQ RCV ) 1) Transmits RSP_PDU

26.3 Acknowledged Sequence of unitdata transfer Service (ASS)

The procedure of ASS is described in Table 125.

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Table 125 – ASS Procedure

Event Condition Procedure

DL-UNITDATA wait_flag = “false” 1) Transmits DT_PDU with V(SQ SND )
request 2) Issues a DL- UNITDATA confirm normally
3) Increments C(OS)
4) Starts T(ID)
wait_flag = “true” 1) Waits until wait flag becomes false
C(OS) = P(MOS) 1) Transmits ENQ_PDU
2) Sets wait_flag
3) Starts T(NR ASS )
T(ID ASS ) =P(TID ASS ) 1) Transmits ENQ_PDU
2) Sets wait_flag
3) Starts T(NR ASS )
T(NR ASS ) = P(TNR ASS ) C(RT ASS ) < P(MRC ASS ) 1) Retransmits ENQ_PDU
2) Increments C(RT ASS )
3) Starts T(NR ASS )
C(RT ASS ) = P(MRC ASS ) 1) Clears wait flag
2) Clears V(SQ SND )
Receive RSP_PDU seqNo = V(SQ SND ) 1) Clears wait_flag
seqNo <> V(SQ SND ) 1) Retransmit DT_PDUs from DT_PDU with seqNo in
&& C(RT ASS ) < P(MRC ASS ) the RSP_PDU
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

2) Transmits ENQ_PDU
3) Increments C(RT ASS )
4) Starts T(NR ASS )
seqNo <> V(SQ SND ) 1) Clears wait_flag
&& C(RT ASS ) = P(MRC ASS ) 2) Clears V(SQ SND )
status = “buffer busy” 1) Retransmit DT_PDUs from DT_PDU with seqNo in
&& C(RT ASS ) < P(MRC ASS ) the RSP_PDU
2) Waits P(TWT ASS )
3) Transmits ENQ_PDU
4) Increments C(RT ASS )
5) Starts T(NR ASS )
status = “buffer busy” 1) Clears wait flag
&& C(RT ASS ) < P(MRC ASS ) 2) Clears V(SQ SND )
Receive DT_PDU seqNo = “0” 1) Issues a DL-UNITDATA indication primitive at the
&& buffer is available DLSAP with DLSDU
2) Clears busy_flag
3) Update V(SQ RCV )
seqNo = V(SQ RCV ) + 1 1) Issues a DL-UNITDATA indication primitive at the
&& buffer is available DLSAP with DLSDU
2) Update V(SQ RCV )
seqNo = V(SQ RCV ) + 1 1) Discard the DT_PDU
&& buffer is not available 2) Sets busy_flag
seqNo <> V(SQ RCV ) + 1 1) no action taken
Receive EQ_PDU busy_flag = “false” 1) Transmits RSP_PUD with V(SQ RCV )
busy_flag = “true” 1) Transmits RSP_PUD with V(SQ RCV ) and “buffer
busy” status

26.4 Multipoint Unitdata transfer Service (MUS)

The procedure of MUS is described in Table 126.

Table 126 – MUS Procedure

Event Condition Procedure

DL-UNITDATA request 1) Sends DT_PDU
2) Issues a DL- UNITDATA confirm
Receive DT_DLPDU 1) Issues a DL-UNITDATA indication primitive at the
DLSAP with DLSDU

26.5 Multipoint Sequence of unitdata transfer Service (MSS)

The procedure of MSS is described in Table 127.

Copyright International Electrotechnical Commission

Table 127 – MSS Procedure

Event Condition Procedure

Receipt of a DL- 1) Sends MSS_DT_PDU on both interfaces
UNITDATA request 2) Initiates a DL- UNITDATA confirm
primitive
Receipt of a ENQ_PUD Requested DT-PDU is 1) Sends MSS_DT_PDUs requested on both
available interfaces again
Receipt of a DT DLPDU seqNo = V(SQ RCV ) + 1 1) Issues a DL-UNITDATA indication primitive at the
DLSAP with DLSDU
2) Updates V(SQ RCV )
seqNo <> V(SQ RCV ) + 1 1) Issues a DL-UNITDATA indication primitive at the
DLSAP with DLSDU and sequence error status
2) Updates V(SQ RCV )

27 DL-support protocol

27.1 Transmission scheduling

27.1.1 Overview

The transmission timing of each DLPDU is scheduled in one or more time slot(s) within the
macro-cycle. These time slots are specified by the system parameters according to the
service subtype and the transmitting station number.

27.1.2 Macro-cycle

The macro-cycle is a base time period in which transmission is controlled. The duration of the
macro-cycle is specified by the parameter macro-cycle-period P(MC). Every node has
synchronized macro-cycle by means of a time synchronization mechanism.
NOTE This synchronization mechanism is outside the scope of Section 5 of this PAS.

27.1.3 Transmission time slot

The transmission time slot for each service subtype is specified by the following parameters:

P(SD XXX ) starting-delay

P(TD XXX ) time-duration
P(TO XXX ) offset-time
P(DV XXX ) divisor-for-grouping
V(TS) this-station
NOTE Suffixes of each parameter (“ XXX ”) indicate the corresponding service subtype.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

The start timing of each slot in the macro-cycle is specified by the following equation:

P(SD XXX ) + (V(TS) % P(DV XXX )) X P(TO XXX )

where “%” indicates the modulo operator.

The end timing of each slot in the macro-cycle is specified by the following equation.

P(SD XXX ) + (V(TS) % P(DV XXX )) X P(TO XXX ) + P(TD XXX )

27.1.4 Transmission scheduling

DT_PDUs are transmitted in the time slot that is selected according to the service subtype of
the DT_PDU, and the other DL_PDUs may be transmitted at any time.

Copyright International Electrotechnical Commission

NOTE As the scheduling is controlled over the UDP service, the actual timing of transmission to medium is
affected by the delay caused by the underlying layer service. Therefore, some considerations are required for
implementation.

27.2 Redundancy

27.2.1 Network redundancy

27.2.1.1 General

The network always has a dual-redundant structure. Both the primary and secondary channels
are diagnosed periodically by the application entities. The information concerning the
consistency of channels is shared among all end nodes of the network and maintained in the
network status table specified in Section 3 of this PAS.

The interface to which DLPDU is transmitted is selected according to the network status table.

Each channel is basically used according to the following rules:

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

a) when both channels are consistent

- use the primary channel
b) when one of channel is inconsistent
- use the consistent channel
c) when both channels are inconsistent
- use the channel that is likely to be consistent between two endpoints

27.2.1.2 Channel redundancy for UUS

The DLE selects a transmission channel for UUS_DLPDUs and receives them as follows:

a) The DLE transmits UUS_DT_PDUs to the channel selected according to the general rule
specified in subclause 27.2.1.1.
b) The DLE receives every UUS_PDU regardless of the receiving channel.

27.2.1.3 Channel redundancy for AUS

The DLE selects a transmission channel for AUS_DLPDUs and receives them as follows:

a) The DLE first transmits a DT_PDU to the channel selected according to the general rule
specified in subclause 27.2.1.1. If errors are detected, the DLL retransmits the DT_PDU to
the same channel. After retransmissions the number of which is half the maximum retry
count, the DLE changes the transmission channel to the alternate channel.
b) The DLE always transmits RSP_PDU to the channel from which the DT_PDU was
received.
c) The DLE receives the AUS_DT_PDU the sequence number of which is not the same as
the value of the last received AUS_DT_PDU from the sending end node, regardless of the
receiving channel.
d) The DLE receives every AUS_RSP_PDU regardless receiving channel.

27.2.1.4 Channel redundancy for ASS

The DLE selects a transmission channel for ASS_DLPDUs and receives them as follows:

a) The DLE transmits a DT_PDU to the channel selected according to the general rule
specified in subclause 27.2.1.1.
b) The DLE transmits an ENQ_PDU to the channel selected according to the general rule
specified in subclause 27.2.1.1.
NOTE The application entity checks the consistency of the channels periodically and updates the network status
table. Consequently, the channel for retransmission is changed to the alternate channel.

Copyright International Electrotechnical Commission

c) The DLE always transmits RSP_PDU to both of the redundant channels.

d) The DLE receives the ASS_DT_PDU the sequence number of which is not the same as
the value of the last received ASS_DT_PDU from the sending end node, regardless of the
receiving channel.
e) The DLE receives the ASS_ENQ_PDU regardless of the receiving channel.
f) The DLE receives the ASS_RSP_PDU regardless of the receiving channel.

27.2.1.5 Channel redundancy for MUS

The DLE selects the transmission channel for MUS_DLPDUs and receive them as follows:

27.2.1.6 Channel redundancy for MSS

The DLE selects the transmission channel for MUS_DLPDUs and receive them as follows:

a) The DLE always transmits DT_PDU for both of the redundant channels. Actually, it is
realized by transmitting to two multicast addresses assigned for the primary and
secondary networks.
b) The DLE receives the MSS_DT_PDU the sequence number of which is not the same as
the value of the last received MSS_DT_PDU from the sending end node, regardless of the
receiving channel.

27.2.2 Station redundancy

27.2.2.1 General

A redundant station consists of two end nodes that have different DLSAPs. One end node is
in the on-service state, and the other end node is in the standby state. Each end node acts
according to its state. The switching over mechanism is outside the scope of this PAS.

27.2.2.2 Actions of peer stations

The DLE of the station that communicates with a redundant station selects one end node of
the redundant station as the destination according to the information in the network status
table, as follows:

a) The DLE transmits UUS_DT_PDU to the end node in on-service state.

b) The DLE first transmits AUS_DT_PDU to the end node in the on-service state. If
communication fails, it then transmits AUS_DT_PDU to the end node in the standby state.
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

c) The DLE transmits ASS_DT_PDU to both of the end nodes.

d) When the DLE user requests communication to the end node in the standby state, the
destination end node is selected accordingly. In this case, the standby side shall be
specified in the PDU type field of the DLPDU.
NOTE Consideration of destination end node is not needed for MUS and MSS communication because the
destination address is a multicast address. This means that the DT_PDU is delivered to both end nodes of the
redundant station.

27.2.2.3 Actions of on-service end node

The DLE of the end node in the on-service state acts as follows:

a) The DLE provides every DLE service to the DLS-user.

b) The DLE accepts every DT_PDU, and pass it to DLE-user by indication primitives.
c) The DLE accepts every ENQ_PDU and responds to it.

Copyright International Electrotechnical Commission

d) The DLE accepts every RSP_PDU responding to the ENQ_PDU sent.

27.2.2.4 Actions of standby end node

The DLE of the end node in the standby state acts as follows:

a) The DLE does not provide any DLE services to the DLS-user, except in the case where
the “standby end node” is specified explicitly.
b) The DLE does not accept any DT_PDUs, except in the case where the “standby end node”
is specified explicitly.
c) The DLE does not respond to any ENQ_PDUs, except in the case where the “standby end
node” is specified explicitly.
d) The DLE does not accept any RSP_PDUs, except in the case where the “standby end
node” is specified explicitly.

27.3 DLPDU authentication

Authentication of the DLPDUs may be applied for UUS_DT_PDUs, AUS_DT_PDUs and

ASS_DT_PDUs. The authentication is realized by the authentication data field in the common
header of the DLPDU.

The sending DLE puts authentication data into the DLPDU. The authentication data are
generated from all octets of the DLPDU except the authentication data field, and the common
secret key shared by both end nodes.

The receiving DLE checks the octets of the DLPDU including the authentication data field with
the common secret key.

The method for authentication data generation and checking is outside the scope of this PAS.

The common secret key is shared by means of the public key exchange method.

Both of the local end nodes generate a private number (x) for each. The method of the private
key generation is outside the scope of this PAS. In addition, the public key (y) is generated
from the prime number (p) and the base number (g) assigned for the network as follows.

y = g^x % p

All end nodes are informed of the public key by multicasting. This is realized by the
application entity using the MUS DLE service.

The common secret key (z) is generated from the private number and the public key of the
peer end node, as follows.

z = y^x % p

The private number (x) shall be updated after every period specified by P(UD).

______________

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

Provided by IHS under license with IEC Licensee=Daewoo Corporation/5908861001
No reproduction or networking permitted without license from IHS Not for Resale, 06/13/2006 23:28:47 MDT
Standards Survey

The IEC would like to offer you the best quality standards possible. To make sure that we
continue to meet your needs, your feedback is essential. Would you please take a minute
to answer the questions overleaf and fax them to us at +41 22 919 03 00 or mail them to
the address below. Thank you!

Customer Service Centre (CSC)

International Electrotechnical Commission
3, rue de Varembé
1211 Genève 20
Switzerland
or

Fax to: IEC/CSC at +41 22 919 03 00

Thank you for your contribution to the standards-making process.

Nicht frankieren
Ne pas affranchir

A Prioritaire
Non affrancare
No stamp required
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

RÉPONSE PAYÉE
SUISSE

Customer Service Centre (CSC)

International Electrotechnical Commission
3, rue de Varembé
1211 GENEVA 20
Switzerland

Copyright International Electrotechnical Commission

Provided by IHS under license with IEC Licensee=Daewoo Corporation/5908861001
No reproduction or networking permitted without license from IHS Not for Resale, 06/13/2006 23:28:47 MDT
Q1 Please report on ONE STANDARD and Q6 If you ticked NOT AT ALL in Question 5
ONE STANDARD ONLY. Enter the exact the reason is: (tick all that apply)
number of the standard: (e.g. 60601-1-1)
.............................................................
standard is out of date R
standard is incomplete R
standard is too academic R
Q2 Please tell us in what capacity(ies) you standard is too superficial R
bought the standard (tick all that apply).
I am the/a:
title is misleading R
I made the wrong choice R
purchasing agent R other ....................................................
librarian R
researcher R
design engineer R Q7 Please assess the standard in the
safety engineer R following categories, using
testing engineer R the numbers:
marketing specialist R (1) unacceptable,
(2) below average,
other.....................................................
(3) average,
(4) above average,
(5) exceptional,
Q3 I work for/in/as a:
(6) not applicable
(tick all that apply)

manufacturing R timeliness .............................................

consultant R quality of writing....................................

technical contents.................................
government R logic of arrangement of contents ..........
test/certification facility R tables, charts, graphs, figures ...............
public utility R other ....................................................
education R
R

--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---
military
other.....................................................
Q8 I read/use the: (tick one)

Q4 This standard will be used for: French text only R

(tick all that apply) English text only R
general reference R both English and French texts R
product research R
product design/development R
specifications R Q9 Please share any comment on any
tenders R aspect of the IEC that you would like
quality assessment R us to know:
certification R ............................................................
technical documentation R ............................................................
thesis R ............................................................
manufacturing R ............................................................
other..................................................... ............................................................
............................................................
............................................................
Q5 This standard meets my needs:
(tick one) ............................................................
............................................................
not at all R ............................................................
nearly R ............................................................
fairly well R ............................................................
exactly R
Copyright International Electrotechnical Commission
Provided by IHS under license with IEC Licensee=Daewoo Corporation/5908861001
No reproduction or networking permitted without license from IHS Not for Resale, 06/13/2006 23:28:47 MDT
--``,`,`,,,,``,,,```,`,`,``,,``-`-`,,`,,`,`,,`---

Copyright International Electrotechnical Commission

ISBN 2-8318-8032-7

-:HSMINB=] UXW\:
ICS 25.040.40; 35.240.50; 35.100.05

Typeset and printed by the IEC Central Office

GENEVA, SWITZERLAND

Copyright International Electrotechnical Commission

Provided by IHS under license with IEC Licensee=Daewoo Corporation/5908861001
No reproduction or networking permitted without license from IHS Not for Resale, 06/13/2006 23:28:47 MDT

Ingles IV
No ratings yet
Ingles IV
124 pages
2 PDF
No ratings yet
2 PDF
414 pages
Not For Sale: Akut Fixed Dome Biogas Plant Volume 48 M
No ratings yet
Not For Sale: Akut Fixed Dome Biogas Plant Volume 48 M
1 page
MTD Exa 22 GVT-137606-001-04
No ratings yet
MTD Exa 22 GVT-137606-001-04
38 pages
EcoStruxure Hybrid DCS Process Control Services User Guide - Eng - EIO0000000988.14
No ratings yet
EcoStruxure Hybrid DCS Process Control Services User Guide - Eng - EIO0000000988.14
616 pages
Iec61158 5 11 (Ed1.0) en
No ratings yet
Iec61158 5 11 (Ed1.0) en
88 pages
Adw300-Mqtt-Json Protocols
No ratings yet
Adw300-Mqtt-Json Protocols
5 pages
Messages 3
No ratings yet
Messages 3
12 pages
IEC 61508 and Functional Safety
No ratings yet
IEC 61508 and Functional Safety
25 pages
Chemlab Review Questions
100% (6)
Chemlab Review Questions
86 pages
TD Jnl1240b Ind04
No ratings yet
TD Jnl1240b Ind04
2 pages
Path Fınder Scanner Owners-Handbook-173858
No ratings yet
Path Fınder Scanner Owners-Handbook-173858
75 pages
Historic Firearms
No ratings yet
Historic Firearms
22 pages
Sample of Literature Review in Research Proposal
100% (1)
Sample of Literature Review in Research Proposal
7 pages
M-7-1 Heat Exchangers
No ratings yet
M-7-1 Heat Exchangers
11 pages
Cem V8 Objects 000 en
No ratings yet
Cem V8 Objects 000 en
705 pages
Connection of Redundant I/O Devices To S7-1500: Lredio Library
No ratings yet
Connection of Redundant I/O Devices To S7-1500: Lredio Library
31 pages
Industrial Networking Solutions For Mission Critical Applications Catalog PDF
No ratings yet
Industrial Networking Solutions For Mission Critical Applications Catalog PDF
136 pages
KTM Newcastle - 65 SX (Eu) 2020 - Rear Brake Control
No ratings yet
KTM Newcastle - 65 SX (Eu) 2020 - Rear Brake Control
1 page
The Future of Energy Storage System Safety
No ratings yet
The Future of Energy Storage System Safety
2 pages
Fujifilm Instax Mini Twin Pack - 20 Instant Color Photo Sheets (Insta Refill)
No ratings yet
Fujifilm Instax Mini Twin Pack - 20 Instant Color Photo Sheets (Insta Refill)
1 page
MatrikonOPC Server For SCADA IEC 60870 User Manual 0
No ratings yet
MatrikonOPC Server For SCADA IEC 60870 User Manual 0
210 pages
009 11367 R14.0 - QSIG System Manual (For PRT)
No ratings yet
009 11367 R14.0 - QSIG System Manual (For PRT)
116 pages
Subject:: 1 August 2018
No ratings yet
Subject:: 1 August 2018
5 pages
GFK-2224P PACS Ethernet Manual
No ratings yet
GFK-2224P PACS Ethernet Manual
298 pages
E&M Voice Card For LOOP-AM3440-A/B/C User'S Manual
No ratings yet
E&M Voice Card For LOOP-AM3440-A/B/C User'S Manual
32 pages
RESULT
No ratings yet
RESULT
9 pages
ALCAD Product List 2
No ratings yet
ALCAD Product List 2
76 pages
Pre-Standard: Publicly Available Specification
No ratings yet
Pre-Standard: Publicly Available Specification
84 pages
IOL-Interface-Spec 10002 V11 Nov10
No ratings yet
IOL-Interface-Spec 10002 V11 Nov10
253 pages
Loop-G7800 PTN: MPLS/CE Packet Transport Network
No ratings yet
Loop-G7800 PTN: MPLS/CE Packet Transport Network
35 pages
Estimates
No ratings yet
Estimates
4 pages
Lijadora 311A
No ratings yet
Lijadora 311A
2 pages
1756 Um058 - en P PDF
No ratings yet
1756 Um058 - en P PDF
258 pages
252 SiPass Int MP2 65SP2 RelNotes A-100083-1 en A
100% (1)
252 SiPass Int MP2 65SP2 RelNotes A-100083-1 en A
40 pages
02 PROFINET-Industrial Ethernet
No ratings yet
02 PROFINET-Industrial Ethernet
288 pages
Refractarios Cleaver Brooks
100% (1)
Refractarios Cleaver Brooks
1 page
Pas 62410
No ratings yet
Pas 62410
118 pages
Iec 61131-9
No ratings yet
Iec 61131-9
4 pages
List ISA Documents
No ratings yet
List ISA Documents
15 pages
2011 Reff2020
No ratings yet
2011 Reff2020
35 pages
IAB - Proj Dimas: Integrated Architecture Builder
No ratings yet
IAB - Proj Dimas: Integrated Architecture Builder
114 pages
BU50A04A00-00E-N - 0401 - 05 (FASTTOOLS Product Overview)
No ratings yet
BU50A04A00-00E-N - 0401 - 05 (FASTTOOLS Product Overview)
37 pages
MT45215 S 121 PDF
No ratings yet
MT45215 S 121 PDF
281 pages
SEL-3555 3555#R2B0 RTAC Rear and Front View
No ratings yet
SEL-3555 3555#R2B0 RTAC Rear and Front View
1 page
Iec TS 62351-3 2007-06 1ed
No ratings yet
Iec TS 62351-3 2007-06 1ed
14 pages
101-0007 USB MicroLink Manual
No ratings yet
101-0007 USB MicroLink Manual
8 pages
IEC60870-5-101 - Test Report FXD
No ratings yet
IEC60870-5-101 - Test Report FXD
23 pages
Severe Weather: Moses Anite Building, 4th-6th Floor, Plot 1B, Block 105, Ganiyu Bola Hussain Close, Lekki
No ratings yet
Severe Weather: Moses Anite Building, 4th-6th Floor, Plot 1B, Block 105, Ganiyu Bola Hussain Close, Lekki
23 pages
Vesna Godina - Anthropological Fieldwork
No ratings yet
Vesna Godina - Anthropological Fieldwork
16 pages
Risk Asessment - Hotel Dammangi Comfort
No ratings yet
Risk Asessment - Hotel Dammangi Comfort
8 pages
PCS7 Mini V81 en PDF
No ratings yet
PCS7 Mini V81 en PDF
120 pages
ECDIS: New Standards & Old Underwater Rocks
No ratings yet
ECDIS: New Standards & Old Underwater Rocks
59 pages
Profibus
No ratings yet
Profibus
60 pages
Standards Compliance According To IEC 61131-3
No ratings yet
Standards Compliance According To IEC 61131-3
11 pages
Your Fortified Intelligent Network Solutions Partner: Communications
No ratings yet
Your Fortified Intelligent Network Solutions Partner: Communications
80 pages
Shell-Petan Internship Presentation
No ratings yet
Shell-Petan Internship Presentation
9 pages
Pas 62419 PDF
No ratings yet
Pas 62419 PDF
18 pages
Understanding Time Current Curves
No ratings yet
Understanding Time Current Curves
5 pages
Construct BST From Given Preorder Traversal
No ratings yet
Construct BST From Given Preorder Traversal
4 pages
Pre-Standard: Publicly Available Specification
No ratings yet
Pre-Standard: Publicly Available Specification
50 pages
LV Electrical System Relay, Protection and Control1
No ratings yet
LV Electrical System Relay, Protection and Control1
20 pages
CE Jan 2013
No ratings yet
CE Jan 2013
68 pages
Pre-Standard: Publicly Available Specification
No ratings yet
Pre-Standard: Publicly Available Specification
20 pages
Sync 2000
No ratings yet
Sync 2000
2 pages
9010-9020 Bulletin - GB
No ratings yet
9010-9020 Bulletin - GB
4 pages
WTS 19 44 Ocec 19 160
No ratings yet
WTS 19 44 Ocec 19 160
1 page
WTS 19 42 Ocec 19 160
No ratings yet
WTS 19 42 Ocec 19 160
1 page
Rockwell Hardness Test
100% (1)
Rockwell Hardness Test
7 pages
Assessment Report
No ratings yet
Assessment Report
16 pages
OPC-2 Installation and Commissioning (MVJ Sun Web Version 4.3) R0-I (Encrypted)
No ratings yet
OPC-2 Installation and Commissioning (MVJ Sun Web Version 4.3) R0-I (Encrypted)
56 pages
Publicly Available Specification: IEC PAS 62400
No ratings yet
Publicly Available Specification: IEC PAS 62400
70 pages
There Are A Number of Points To Consider in A Pressure Measurement Application
No ratings yet
There Are A Number of Points To Consider in A Pressure Measurement Application
4 pages
There Are A Number of Points To Consider in A Pressure Measurement Application
No ratings yet
There Are A Number of Points To Consider in A Pressure Measurement Application
4 pages
Manual For As-I Master CM 1243-2 and As-I Data Decoupling Unit DCM 1271 For SIMATIC S7-1200
No ratings yet
Manual For As-I Master CM 1243-2 and As-I Data Decoupling Unit DCM 1271 For SIMATIC S7-1200
134 pages
IEC61131 Fast Guide R1
No ratings yet
IEC61131 Fast Guide R1
5 pages
Bench Marking For Coal Preparation
No ratings yet
Bench Marking For Coal Preparation
10 pages
Benjamin: Location Oceon Office Week #
No ratings yet
Benjamin: Location Oceon Office Week #
1 page
Benjamin: Location Oceon Office Week #
No ratings yet
Benjamin: Location Oceon Office Week #
1 page
Residential Driveway Standards: V I L L A G e o F R o y A L P A L M B e A C H, F L o R I D A
No ratings yet
Residential Driveway Standards: V I L L A G e o F R o y A L P A L M B e A C H, F L o R I D A
1 page
Sicam Ak Sicam Ak 3 Sicam TM Sicam BC SM-2558/ETA4: Protocol Elements For Ethernet TCP/IP
No ratings yet
Sicam Ak Sicam Ak 3 Sicam TM Sicam BC SM-2558/ETA4: Protocol Elements For Ethernet TCP/IP
16 pages
Modbus Client Driver
No ratings yet
Modbus Client Driver
9 pages
Modbus Communication For RTU Slaves
No ratings yet
Modbus Communication For RTU Slaves
15 pages
2VAA001711 - en S Control SPCPM02 Communication Port Module
No ratings yet
2VAA001711 - en S Control SPCPM02 Communication Port Module
63 pages
Connected Components Workbench - 12.00.00 (Released 3 - 2019)
No ratings yet
Connected Components Workbench - 12.00.00 (Released 3 - 2019)
9 pages
IGW-VM Brochure 2022
No ratings yet
IGW-VM Brochure 2022
4 pages
Monthly HSEQ Performance - JANUARY - 2020
No ratings yet
Monthly HSEQ Performance - JANUARY - 2020
2 pages
MJ 11032 G Hyundai Blower
No ratings yet
MJ 11032 G Hyundai Blower
4 pages
HART in Security
No ratings yet
HART in Security
55 pages
6301!0!C - Manual Programare en
No ratings yet
6301!0!C - Manual Programare en
55 pages
Rsnetworx For Devicenet PDF
No ratings yet
Rsnetworx For Devicenet PDF
58 pages
Module and Phase Classes Parameter Reference Paths and Aliases
No ratings yet
Module and Phase Classes Parameter Reference Paths and Aliases
3 pages
DA3400 3600A Guide
No ratings yet
DA3400 3600A Guide
84 pages
Swep Industrial en
No ratings yet
Swep Industrial en
2 pages
Ab PLC Cables
No ratings yet
Ab PLC Cables
14 pages
As IEC 61131.2-2004 Programmable Controllers Equipment Requirements and Tests
No ratings yet
As IEC 61131.2-2004 Programmable Controllers Equipment Requirements and Tests
14 pages
IConf - Master.exp422 Rev02
No ratings yet
IConf - Master.exp422 Rev02
11 pages
TS PcVue12 Communication Drivers en
No ratings yet
TS PcVue12 Communication Drivers en
6 pages
HIMA Safe Ethernet
No ratings yet
HIMA Safe Ethernet
6 pages
Performance of Bored Piles Constructed Using Polymer Fluids: Lessons From European Experience
No ratings yet
Performance of Bored Piles Constructed Using Polymer Fluids: Lessons From European Experience
9 pages
I/A Series Hardware: ® Product Specifications
No ratings yet
I/A Series Hardware: ® Product Specifications
16 pages
Chiller - How It Works - Single Effect
100% (1)
Chiller - How It Works - Single Effect
4 pages
Nyy - Iec PDF
No ratings yet
Nyy - Iec PDF
5 pages
Pressure Transmitter Calibration at The Bench
No ratings yet
Pressure Transmitter Calibration at The Bench
2 pages
Pressure Transmitter Calibration at The Bench
No ratings yet
Pressure Transmitter Calibration at The Bench
2 pages
Prosoft - Modbus PLX31-MBTCP-MBS
No ratings yet
Prosoft - Modbus PLX31-MBTCP-MBS
3 pages
Gs33l50e20-40e 003
No ratings yet
Gs33l50e20-40e 003
4 pages
DeviceNet The Ultimate Step-By-Step Guide
From Everand
DeviceNet The Ultimate Step-By-Step Guide
Gerardus Blokdyk
No ratings yet