Lag 14

LON Application Guidelines
for Substation Automation
Version 1.4
Date 98-09-08 Pages 216

LON Application Guidelines for Substation Automation Version 1.4 Aug. 98
,QWURGXFWLRQ
This paper describes the use of LonWorks Network and its protocol LonTalk protocol in protection
and control systems used in medium or high voltage substations, power stations or in industrial
power distribution.
The purpose of this paper is to outline possible physical structures, message formats, communication
procedures and different system aspects.
The term “LON-bus” implies the use of the LonWorks Network as described in this document.
Two main categories of devices were kept in mind when this paper was written:
- devices which are mainly sold as part of ABB’s own substation automation systems and
compatibility with existing ABB’s systems is the most important factor
- devices which are also sold to open industrial or utility market.
Those devices, which are sold as part of ABB’s substation automation systems, will exchange data
using data formats and procedures optimised for ABB’s Substation Automation purposes.
For devices, which are sold to the open market, conformance to LonMark Application Layer
Interoperability Guidelines is important. This means the use of network variables of standardised
types (SNVTs), modelling the device by using LonMark Objects (node object, sensor objects,
actuator objects and controller objects) and transfer of parameters using network variables or
configuration parameter files.
The intended audience of this paper is design engineers and other technical people. This paper uses
names and terms from the papers of Echelon Corporation and Motorola Inc. listed in the references.
Refererences are indicated by [ref] in the document, further information for the reference are listed in
References.
It is assumed, that the reader has the general knowledge about the LonWorks network, its operation
principles and Echelon’s and other manufacturer’s LonWorks products.
This paper may contain errors and incomplete definitions. This is mainly due to the tough time-table
of the first delivery projects. The work with this paper will continue to make corrections and
additions.
Possible comments to this paper should be sent to :

ABB T&D Technology Ltd, P.O. Box 5102 , CH-5405 Baden-Dättwil, Switzerland
Echelon, LON, LonBuilder, LonManager, LonTalk, Neuron and 3150 are U.S. registered trademarks of Echelon Corporation. LonLink,
LONMARK, LonSupport, LonUsers, LONWORKS, LonMaker, and 3120 are trademarks of Echelon Corporation.
This document is an intellectual property of ABB Transmit Oy, ABB Calor Emag AG, ABB Netzleittechnik AG, ABB Network Partner AG, ABB
Network Partner AB and may not be distributed nor used by other parties without a written permission from the ABB T&D Technology Ltd.
PRG 3DJH
2 / 216 6SHF&/$
7DEOHRI&RQWHQWV
,1752'8&7,21
7$%/(2)&217(176
'(),1,7,216$1'$%%5(9,$7,216
&21),*85$7,216758&785(6
3.1 GENERAL ................................................................................................................................................................ 11
3.2 STAR COUPLER ........................................................................................................................................................ 11
3.3 TYPICAL LON-BUS CONFIGURATIONS ..................................................................................................................... 12
3.4 A SYSTEM WITH SINGLE MONITORING DEVICE ......................................................................................................... 13
3.5 A SYSTEM WITH TWO MONITORING DEVICES ........................................................................................................... 14
3.6 BIG SYSTEM WITH MULTIPLE SUBNETS .................................................................................................................... 15
3.7 A SYSTEM WITH INTERFACE TO STANDARD INDUSTRIAL LON NETWORK ............................................................... 16
&20081,&$7,21352&('85(6
4.1 GENERAL ................................................................................................................................................................ 17
&RPPXQLFDWLRQFDWHJRULHV
/RQWDONDSSOLFDWLRQOD\HUSURWRFRO
4.1.2.1 Network variables .........................................................................................................................................................21
4.1.2.2 Explicit messages ..........................................................................................................................................................21
7UDQVSRUWVHUYLFHVDQGDGGUHVVLQJSRVVLELOLWLHVSURYLGHGE\/RQ7DONSURWRFRO
6HUYLFHW\SHVDGGUHVVLQJIRUPDWVDQGWLPHUYDOXHV
1HWZRUNYDULDEOHQDPLQJFRQYHQWLRQV
0HVVDJHOHQJWK
4.1.6.1 Maximum length of message used on LON-bus ...........................................................................................................25
4.1.6.2 Background ...................................................................................................................................................................25
/RQ7DONILOHWUDQVIHUSURWRFRO
4.1.7.1 Predefined nv indexes and selector values ....................................................................................................................26
4.1.7.2 File directories...............................................................................................................................................................27
$%%DSSOLFDWLRQSURWRFRO
4.1.8.1 Introduction...................................................................................................................................................................28
4.1.8.2 Signal/Message Description.........................................................................................................................................31
4.1.8.3 Session Properties .........................................................................................................................................................32
4.1.8.4 Network TPDU/TPCU format......................................................................................................................................33
4.1.8.5 Session Protocol ............................................................................................................................................................34
4.1.8.6 Transport Protocol.........................................................................................................................................................37
4.1.8.6.1 Data integrity..........................................................................................................................................................37
4.1.8.6.2 Data flow control....................................................................................................................................................38
4.1.8.6.3 Transmitter Procedures...........................................................................................................................................39
4.1.8.6.4 Receiver Procedures ..............................................................................................................................................42
4.1.8.6.5 TPDU / TPCU flow diagrams ................................................................................................................................44
4.1.8.6.6 Transport protocol timers .......................................................................................................................................49
4.2 HORIZONTAL COMMUNICATION .............................................................................................................................. 50
*XLGHOLQHVIRU19ELQGLQJ
$OORFDWLRQRI3ULRULW\VORWV
&RPPXQLFDWLRQVHUYLFHVIRU19GDWDH[FKDQJH
*XLGHOLQHVIRUVHWWLQJ1HXURQFKLSSDUDPHWHUVDQGEXIIHUFRXQWV
4.3 VERTICAL COMMUNICATION ................................................................................................................................... 52
*HQHUDO
,QLWLDOL]DWLRQRIWKHHYHQWVHVVLRQV
4.3.2.1 General..........................................................................................................................................................................52
4.3.2.2 Event session.................................................................................................................................................................52
4.3.2.3 Event filters...................................................................................................................................................................53
4.3.2.4 Event history .................................................................................................................................................................53
PRG 3DJH
3 / 216 6SHF&/$
4.3.2.5 Establishing the event session .......................................................................................................................................53

4.3.2.6 Closing the event session ..............................................................................................................................................55
4.3.2.7 General interrogation ....................................................................................................................................................56
4.3.2.8 Setup Session ................................................................................................................................................................57
4.3.2.8.1 Establishing the setup session.................................................................................................................................57
4.3.2.8.2 Closing the setup session........................................................................................................................................59
4.3.2.8.3 Setup session with multiple clients.........................................................................................................................59
&RPPDQGKDQGOLQJ
4.3.3.1 Command transfer.........................................................................................................................................................64
4.3.3.2 Commands transfered as SPA Message ........................................................................................................................65
)LOH7UDQVIHU
7UDQVSDUHQW'DWD7UDQVIHU
3DUDPHWHUWUDQVIHU
'LVWXUEDQFHUHFRUGHUILOHV
&RQILJXUDWLRQILOHV
7UDQVIHURI&RXQWHU9DOXHV
4.4 LSG COMMUNICATION............................................................................................................................................ 68
3URFHVVGDWDWUDQVIHU
4.4.1.1 Network variables .........................................................................................................................................................68
4.4.1.2 LSG events....................................................................................................................................................................69
4.4.1.3 Control commands ........................................................................................................................................................69
3DUDPHWHUGDWDWUDQVIHU
&RQILJXUDWLRQGDWDWUDQVIHU
/6*WLPHV\QFKURQLVDWLRQ
4.5 INTEROPERABLE COMMUNICATION ......................................................................................................................... 71
2EMHFWPRGHO
3URFHVVGDWDWUDQVIHU
&RQILJXUDWLRQILOHV
4.6 SYSTEM CO-ORDINATION ........................................................................................................................................ 76
1HWZRUN0DQDJHPHQW
4.6.1.1 Network Management responsibility ............................................................................................................................76
4.6.1.2 The task of the Network Management ..........................................................................................................................76
4.6.1.3 Self Identification and Self Documentation Information ..............................................................................................77
,QLWLDOLVDWLRQDQGVWDUWXS
4.6.2.1 General..........................................................................................................................................................................80
4.6.2.2 Cyclic background sending of network variables..........................................................................................................80
4.6.2.3 Cyclic network variable polling ....................................................................................................................................81
1HWZRUNVXSHUYLVLRQ
4.6.3.1 Node supervision...........................................................................................................................................................81
4.6.3.2 Status and error messages .............................................................................................................................................81
4.6.3.2.1 Start up procedure ..................................................................................................................................................81
4.6.3.2.2 Status and error conditions .....................................................................................................................................81
4.6.3.2.3 Event buffer overflow.............................................................................................................................................82
7LPHV\QFKURQL]DWLRQ
4.6.4.1 Synchronization using SNVT_time_stamp ...................................................................................................................83
4.6.4.2 Synchronization using NV_clock_warning and NV_clock...........................................................................................83
4.6.4.3 Very accurate time synchronisation VATS...................................................................................................................84
4.6.4.4 Detail description of time synchronization methods .....................................................................................................85
4.6.4.4.1 NV Warning Principle............................................................................................................................................85
4.6.4.4.2 Requirements on the different devices. ..................................................................................................................85
4.6.4.4.3 LON-bus clock master............................................................................................................................................86
4.6.4.4.4 Monitoring node as clock master............................................................................................................................86
4.6.4.4.5 Multiple subnets .....................................................................................................................................................86
4.6.4.4.6 Propagation time compensation..............................................................................................................................86
4.6.4.4.7 Remotely located nodes..........................................................................................................................................87
'$7$)250$76
5.1 GENERAL ................................................................................................................................................................ 88
5.2 LON SPECIFIC DATAFORMATS ............................................................................................................................... 88
1HWZRUNYDULDEOHGDWDIRUPDW
([SOLFLWPHVVDJHGDWDIRUPDW
5.2.2.1 Application data messages ............................................................................................................................................88
PRG 3DJH
4 / 216 6SHF&/$
5.2.2.2 Network management commands .................................................................................................................................88

5.2.2.3 Network diagnostic commands .....................................................................................................................................89
5.2.2.4 Foreign frame messages ................................................................................................................................................89
5.3 DATA FORMATS FOR HORIZONTAL COMMUNICATION .............................................................................................. 90
5.4 DATA FORMATS FOR VERTICAL COMMUNICATION ................................................................................................... 90
*HQHUDO
'DWDPHVVDJHVLQ0RQLWRULQJDQG&RQWUROGLUHFWLRQ
5.4.2.1 General format definition ..............................................................................................................................................90
5.4.2.2 ABB application protocol flow control bytes................................................................................................................97
5.4.2.3 Cause of transmission (COT) ........................................................................................................................................98
5.4.2.4 Variable Structure Qualifier (VSQ) ..............................................................................................................................99
5.4.2.5 Addressing ..................................................................................................................................................................100
5.4.2.5.1 Unit No.................................................................................................................................................................100
5.4.2.5.2 Object No. ............................................................................................................................................................100
5.4.2.5.3 SPA bay control units, protection relays ..............................................................................................................101
5.4.2.6 Reserved object numbers ............................................................................................................................................101
5.4.2.7 ASDU_No...................................................................................................................................................................102
'0&'W\SHV'DWDW\SHVLQ0RQLWRULQJDQG&RPPDQG'LUHFWLRQ
'0&'7\SH,GHQWLILFDWLRQ
5.4.4.1 Information elements ..................................................................................................................................................105
5.4.4.1.1 ACR = Application Command Response .............................................................................................................105
5.4.4.1.2 AFQ = Acknowledge File Qualifier .....................................................................................................................105
5.4.4.1.3 ASC = ASCII Character .......................................................................................................................................105
5.4.4.1.4 AVA = Attribute Value ........................................................................................................................................105
5.4.4.1.5 BCR = Binary counter reading .............................................................................................................................106
5.4.4.1.6 BSI = Binary State Information............................................................................................................................106
5.4.4.1.7 CHS = Checksum .................................................................................................................................................106
5.4.4.1.8 CPT = Time tag information ................................................................................................................................107
5.4.4.1.9 CP16 = Two Octet Binary Time...........................................................................................................................107
5.4.4.1.10 CQS = Counter Qualifier with Sequence ...........................................................................................................108
5.4.4.1.11 DCO = Double Command..................................................................................................................................108
5.4.4.1.12 DPI = Double Point Information ........................................................................................................................108
5.4.4.1.13 DPI_rev= Double Point Information reversed....................................................................................................109
5.4.4.1.14 DIQ = Double-Point Information with Quality Descriptor ................................................................................109
5.4.4.1.15 DIQ_rev = Double-Point Information with Quality Descriptor reversed ...........................................................110
5.4.4.1.16 EQL1 = Error Qualifier Level 1 .........................................................................................................................110
5.4.4.1.20 ESQ = Event Setup Qualifier ............................................................................................................................111
5.4.4.1.21 FAN = Fault Number (16 bit).............................................................................................................................111
5.4.4.1.22 FRQ = File Ready Qualifier ...............................................................................................................................111
5.4.4.1.23 LSQ Last Segment Qualifier ..............................................................................................................................112
5.4.4.1.24 LOFD = Lenght of File or Directory..................................................................................................................112
5.4.4.1.25 LOS = Lenght of Segment .................................................................................................................................112
5.4.4.1.26 LOV = Length of Attribut Value........................................................................................................................112
5.4.4.1.27 LTD = Length of Transparent Data....................................................................................................................112
5.4.4.1.28 MLQ = Measured value limit quality.................................................................................................................113
5.4.4.1.29 NOFD = Name of File or Directory ...................................................................................................................114
5.4.4.1.30 OAD = Originator Address ................................................................................................................................114
5.4.4.1.31 OCI = Output circuit information of protection equipment................................................................................114
5.4.4.1.32 PCQ = Pulse counter qualifier............................................................................................................................115
5.4.4.1.33 QCC = Qualifier of Counter Interrogation Command........................................................................................115
5.4.4.1.34 QDP = Quality Descriptor for events of Protection Equipment .........................................................................116
5.4.4.1.35 QDS = Quality Descriptor, Separate Octet.........................................................................................................117
5.4.4.1.36 QOC = Qualifier of Command...........................................................................................................................118
5.4.4.1.37 QOI = Qualifier of Interrogation ........................................................................................................................118
5.4.4.1.38 QST = Queue State.............................................................................................................................................118
5.4.4.1.39 QUT = Queue Type............................................................................................................................................118
5.4.4.1.40 RCO = Regulating Step Command ....................................................................................................................119
5.4.4.1.41 SCQ = Select and Call Qualifier ........................................................................................................................120
5.4.4.1.42 SCO = Single Command ....................................................................................................................................120
5.4.4.1.43 SEP = Single-Event of protection equipment.....................................................................................................121
5.4.4.1.44 SIQ = Single-Point Information with Quality Descriptor...................................................................................122
5.4.4.1.45 SOFD = Status of File or Directory....................................................................................................................122
PRG 3DJH
5 / 216 6SHF&/$
5.4.4.1.46 SPE = Start events of protection equipment.......................................................................................................123

5.4.4.1.47 SPI = Single-Point Information..........................................................................................................................124
5.4.4.1.48 SSQ = Setup Session Qualifier...........................................................................................................................124
5.4.4.1.49 SVAF = Short floating point number (Scaled value floating) ............................................................................124
5.4.4.1.50 TCI = Time Counter Interrogation .....................................................................................................................125
5.4.4.1.51 TOH = Type of Handling ...................................................................................................................................125
5.4.4.1.52 TOV = Type of Object Value.............................................................................................................................125
5.4.4.1.53 VAI = Signed integer information (16 bit).........................................................................................................125
5.4.4.1.54 VAI32 = Signed integer information (32 bit).....................................................................................................126
5.4.4.1.55 VTI = Value with Transient State Indication .....................................................................................................126
5.4.4.2 Definition and Presentation of ASDU’s (DMCD types)..............................................................................................127
5.4.4.2.1 Commands............................................................................................................................................................127
5.4.4.2.1.1 DMCD type = 45 = C_SC_N , Single Command .........................................................................................127
5.4.4.2.1.2 DMCD type = 46 = C_DC_N , Double Command .......................................................................................128
5.4.4.2.1.3 DMCD type = 47 = C_RC_N , Regulating Step Command .........................................................................129
5.4.4.2.1.4 DMCD type = 48 = C_SE_NA , Set-Point Command, Signed Integer 32 bit: .............................................130
5.4.4.2.1.5 DMCD type = 50 = C_SE_NC , Set-Point Command, Short Floating Point Number: .................................131
5.4.4.2.1.6 DMCD type = 51 = C_BO_NA , Bitstring Command, 32 Bit: .....................................................................132
5.4.4.2.1.7 DMCD type = 101 = C_CI_N , Counter Interrogation Command................................................................133
5.4.4.2.1.8 DMCD type = 110 = C_GO_N , General Object Handling Command.........................................................134
5.4.4.2.1.9 DMCD type = 228 = C_IC_NA, GI command/response ..............................................................................135
5.4.4.2.1.10 DMCD type = 229 = C_ES_NA, ES command/response..........................................................................136
5.4.4.2.1.11 DMCD type = 230 = C_SS_NA, Setup Session command/response.........................................................137
5.4.4.2.2 Events...................................................................................................................................................................138
5.4.4.2.2.1 DMCD type =129 = M_SP_N, Single-point information without Time Tag ...............................................138
5.4.4.2.2.2 DMCD type =130 = M_SP_T, Single-point information with Time Tag .....................................................139
5.4.4.2.2.3 DMCD type =131 = M_DP_NR, Double-point information without Time Tag (reversed)..........................140
5.4.4.2.2.4 DMCD type =132 = M_DP_TR, Double-point information with Time Tag (reversed) ...............................140
5.4.4.2.2.5 DMCD type =133 = M_BO_N, Bitstring of 32 bit without Time Tag .........................................................141
5.4.4.2.2.6 DMCD type =134 = M_BO_T, Bitstring of 32 bit with Time Tag...............................................................142
5.4.4.2.2.7 DMCD type =135 = M_MEN_N, Measured value, signed integer without Time Tag.................................143
5.4.4.2.2.8 DMCD type =136 = M_MEN_T, Measured value, signed integer with Time Tag ......................................144
5.4.4.2.2.9 DMCD type =137 = M_MEF_N, Measured value, short floating point without Time Tag .........................145
5.4.4.2.2.10 DMCD type =138 = M_MEF_T, Measured value, short floating point with Time Tag.............................146
5.4.4.2.2.11 DMCD type =139 = M_PC_T, Pulse counter value with Time Tag ..........................................................147
5.4.4.2.2.12 DMCD type = 140 = M_IT_T, Integrated Totals with Time Tag...............................................................148
5.4.4.2.2.13 DMCD type = 141 = M_ST_N, Step Position Information ........................................................................149
5.4.4.2.2.14 DMCD type = 142 = M_ST_T, Step Position Information with Time Tag................................................150
5.4.4.2.2.15 DMCD type =143 = M_DP_N, Double-point information without Time Tag ...........................................151
5.4.4.2.2.16 DMCD type =144 = M_DP_T, Double-point information with Time Tag.................................................151
5.4.4.2.2.17 DMCD type =147 = M_MEI_N, Measured value, signed integer 32 bit without Time Tag ......................152
5.4.4.2.2.18 DMCD type =148 = M_MEI_T, Measured value, signed integer 32 bit with Time Tag ...........................153
5.4.4.2.2.19 DMCD type = 154 = M_EP_TA , Event of protection equipment with Time Tag.....................................154
5.4.4.2.2.20 DMCD type = 155 = M_EP_TB , Packed Start Event of protection equipment with Time Tag................155
5.4.4.2.2.21 DMCD type = 156 = M_EP_TC , Packed Output circuit information of protection equipment with Time
Tag 156
5.4.4.2.3 File Transfer .........................................................................................................................................................157
5.4.4.2.3.1 DMCD type = 120 = F_FR_N , File Ready..................................................................................................157
5.4.4.2.3.2 DMCD type = 122 = F_SC_N , Call Directory, Select File, Call file...........................................................157
5.4.4.2.3.3 DMCD type = 123 = F_LS_N , Last Segment..............................................................................................158
5.4.4.2.3.4 DMCD type = 124 = F_AF_N, Ack File ......................................................................................................158
5.4.4.2.3.5 DMCD type = 125 = F_SG_N , Segment: ....................................................................................................159
5.4.4.2.3.6 DMCD type = 126 = F_DR_T , Directory....................................................................................................160
5.4.4.2.4 Diagnosis Information ..........................................................................................................................................161
5.4.4.2.4.1 DMCD type = 201 = M_GD_T , Generic Diagnosis Information Time Tagged with Qualifier...................161
5.4.4.2.5 Transparent Data ..................................................................................................................................................162
5.4.4.2.5.1 DMCD type = 231 = T_TD_N , Transparent Data: ......................................................................................162
5.5 DATA FORMATS FOR LSG COMMUNICATION ......................................................................................................... 163
1HWZRUNYDULDEOHV
5.5.1.1 NV type 83 = SNVT_state ..........................................................................................................................................163
5.5.1.2 NV type 250 = NV_control.........................................................................................................................................164
5.5.1.3 NV type 251 = NV_bit_write (BWR) .........................................................................................................................165
5.5.1.4 NV type 252 = NV_32b_analog..................................................................................................................................166
5.5.1.5 NV type 253 = NV_16b_analog..................................................................................................................................167
/6*(YHQW0HVVDJHV
PRG 3DJH
6 / 216 6SHF&/$
5.5.2.1 LSG event type 0 = LSG SPA event ...........................................................................................................................170

5.5.2.2 LSG event type 1 = LSG analog event.......................................................................................................................171
5.5.2.3 LSG event type 2 = LSG digital event ........................................................................................................................172
5.5.2.4 LSG event type 7 = LSG SPA analogue event............................................................................................................173
5.5.2.5 LSG event type 8 = LSG extended SPA event............................................................................................................174
/6*&RQILJXUDWLRQ0HVVDJHV
7UDQVSDUHQW63$EXVPHVVDJHV
5.5.4.1 SPA parameter read message ......................................................................................................................................178
5.5.4.2 SPA parameter write message.....................................................................................................................................179
5.6 DATA FORMATS FOR INTEROPERABLE COMMUNICATION ....................................................................................... 180
5HFRPPHQGHG6WDQGDUG1HWZRUN9DULDEOH7\SHV6197
5.6.1.1 NV type 8 = SNVT_count...........................................................................................................................................180
5.6.1.2 NV type 22 = SNVT_lev_disc ....................................................................................................................................180
5.6.1.3 NV type 83 = SNVT_state ..........................................................................................................................................180
5.6.1.4 NV types “f” = floating point SNVTs ......................................................................................................................181
5.6.1.5 NV type 88 = SNVT_alarm ........................................................................................................................................182
5.6.1.6 NV type 93 = SNVT_obj_status .................................................................................................................................184
5.6.1.7 NV type 92 = SNVT_obj_request ...............................................................................................................................185
5.7 DATA FORMATS FOR SYSTEM CO-ORDINATION MESSAGES..................................................................................... 186
)RUPDWRIQHWZRUNPDQDJHPHQWPHVVDJHV
5.7.1.1 Update Extended Address message.............................................................................................................................187
5.7.1.2 Query Extended Address message ..............................................................................................................................188
5.7.1.3 Update Extended Net Variable Config message .........................................................................................................189
5.7.1.4 Query Extended Net Variable Config message...........................................................................................................191
)RUPDWRILQLWLDOL]DWLRQDQGVWDUWXSPHVVDJHV
5.7.2.1 Session setup messages ...............................................................................................................................................192
5.7.2.2 Session control messages ............................................................................................................................................192
5.7.2.2.1 s-conn.req, Session connection request ................................................................................................................192
5.7.2.2.2 s-conn.reject or s-disconn.req, Session connection rejected or disconnected ......................................................192
5.7.2.2.3 s-conn.accept, Session connection accepted.........................................................................................................192
5.7.2.3 Transmission control messsages .................................................................................................................................193
5.7.2.3.1 TranNack, Transmission sequence not acknowledged ........................................................................................193
5.7.2.3.2 TranAck, Transmission sequence acknowledged .................................................................................................193
5.7.2.3.3 AckReq, Acknowledgement request ...................................................................................................................193
5.7.2.4 General interrogation messages...................................................................................................................................195
)RUPDWRIQHWZRUNVXSHUYLVLRQPHVVDJHV
5.7.3.1 Node supervision messages.........................................................................................................................................196
5.7.3.2 Status and error messages ...........................................................................................................................................196
)RUPDWRIWLPHV\QFKURQLVDWLRQPHVVDJHV
5.7.4.1 NV type 255 = NV_clock ...........................................................................................................................................197
5.7.4.2 NV type 254 = NV_clock_warning.............................................................................................................................198
5.7.4.3 NV type 249 = NV_time .............................................................................................................................................199
5.7.4.4 NV type 248 = NV_sync_time....................................................................................................................................200
)RUPDWRI7UDQVSDUHQW'DWDQHWZRUN9DULDEOH
5.7.5.1 NV type 247 = NV_t_data ..........................................................................................................................................201
5()(5(1&(6
5(9,6,21,1)250$7,21
$33(1',;3(5)250$1&(2)/211(7:25.,17(5)$&(
$33(1',;*(1(5$//210(66$*()250$7
$33(1',;'()$8/71(7:25.9$5,$%/(6(/(&7259$/8(6$1',1'(;(6
$33(1',;6800$5<2)1(7:25.9$5,$%/(7<3(6
$33(1',;1(8521&+,33$5$0(7(56$1'%8))(5&28176

$SSHQGL[)LOH7UDQVIHU«««««««««««««««««««««««««««««««
PRG 3DJH
7 / 216 6SHF&/$
'HILQLWLRQVDQGDEEUHYLDWLRQV
,QWHURSHUDELOLW\
A condition that ensures that multiple nodes (from the same or different
manufacturers) can be integrated into a single network without requiring custom
node or tool development. At application layer, interoperability between
LonWorks-based products is facilitated through the use of LonMark objects and
SNVTs.
/21
Local Operating Network
/21EXV
A name given to our way of using LonWorks Network in Substation Automation
applications, referring especially to the fibre-optic physical star network structure
and our own message and data formats.
/RQ0DUN
LonMark interoperability association is an independent world-wide industry
association, which facilitates the development and implementation of open,
interoperable LonWork based control products and systems. LonMark
association includes manufacturers, end-users and integrators of LonWorks
products. The association establishes guidelines such as “LonMark Application
Layer Interoperability Guidelines”.
/RQ0DUNREMHFW
A set of one or more network variable inputs and/or outputs implemented as
SNVTs with semantic definitions relating the behaviour of the object to the
network variable values, in addition to a set of configuration properties.
/RQ7DONSURWRFRO
Communication protocol used in LonWorks networks.
/RQ:RUNVQHWZRUN
A communication network built using LonWorks technology, including e.g.
Neuron chip and LonTalk protocol.
0RQLWRULQJGHYLFH
A device in substation automation system, which collects alarm and event
information from the other devices to be further transferred to another system or
to be presented to the user. The devices also provide controlling interface for the
system.
1&&
Network Control Center
PRG 3DJH
9 / 216 6SHF&/$
1HWZRUNYDULDEOH
A data item in LonTalk application protocol containing max. 31 bytes of data.
Network variables are addressed on application level using network variable
selectors. The selector is a 14-bit number in the range 0...12287 (2FFFH). The
selector is used a network wide identification of the Network Variable.
6197
Standard Network Variable type. The definition of a SNVT includes unit, range,
resolution and data format. SNVTs are listed in the SNVT Master List and
Programmer’s Guide. This list is updated by Echelon and it includes network
variable types, which are commonly agreed to be used by multiple manufacturers.
6&6
Substation Control System
73&8
Transport Protocol Control Unit
A message with transport control information only . These messages are volatile,
and will not be retransmitted if lost
73'8
Transport Protocol Data Unit
A message with transport control information and some higher layer information.
These messages will have a sequence number, and the Transport Provider will
retransmit the message until it is acknowledged.
PRG 3DJH
10 / 216 6SHF&/$
&RQILJXUDWLRQVWUXFWXUHV
This chapter describes possible structure of the LON-bus system. The use of star-
couplers and routers will be described. The maximum number of nodes in
different system configurations will be indicated.
Usually a LON-bus system, which is used for Substation Automation purposes

includes one or more devices which collect alarm and event information from the
other devices to be further transferred to another system or to be presented to the
user. The devices also provide controlling interface of the system. In this paper
these devices are called monitoring devices. Typical examples of monitoring
devices are SCS computer and NCC gateway (Network Control Centre gateway).
*HQHUDO
Physical layer media of the LON-bus is fibre optic cabling. The physical network
is star network implemented using star-couplers. The default speed of the
network is 1.25 Megabits per second.
Interfaces to other types of network cabling (e.g. transformer isolated twisted

pair) can be arranged using LonWorks Routers. Also network parts with
different speed than 1.25 Mbits/s can be used in the system with the help of
routers. Routers are standalone products (e.g. from Echelon corporation) or
option cards in star-couplers.
6WDUFRXSOHU
The star couplers contain 3 or more fibre optic connections, each connection
being a transmitter-receiver pair. The star couplers may be hierarchically
arranged in two layers as illustrated in the following figures. The arrangement
should be done so that a message sent from any of the devices in the system
should not go through more than three star couplers to reach any other device in
the system.
Two devices may also be chained together using a LON interface module with
two fibre optic connections. In this case one connection of the LON interface
module is connected to a star coupler and the other is connected to another
device’s LON interface module. Care must be taken when building the system, a
message sent by any of the devices in the system should not go through more than
six fibre optic cable lines before reaching any other device in the system.
The maximum recommended distance between any two devices connected with
fibre optic cables to the same system is 2000m.
The limitations in the fibre optic cable arrangements are done in order to control
the pulse width distortion caused by the fibre optic transmitter and receiver.
PRG 3DJH
11 / 216 6SHF&/$
7\SLFDO/21EXVFRQILJXUDWLRQV
The maximum number of devices, which can be connected together with one star-
coupler (type RER111) is 27. (RER111 includes 9 cards each of which can have
3 fibre optic interfaces.) (See figures 3 and 4).
In big substations where the number of devices is bigger than 27, more than one
star coupler is needed. If the message load of the system is big, routers may have
to be used to divide the LON-bus into several subnets. In case routers are used to
separate subnets, SCS and NCC Gateway have multiple LON interfaces, one
interface for each subnet (see figure 5).
The following pictures show some examples of the maximum number of possible
bay units with different amount of star-couplers (RER111), and different amount
of monitoring devices.
PRG 3DJH
12 / 216 6SHF&/$
$V\VWHPZLWKVLQJOHPRQLWRULQJGHYLFH
The only monitoring device of a small system is usually a gateway

communicating with Network Control Centre or another type of higher level
control system. Time tagged events are sent to the gateway and control
commands are sent to the relays and control units by it.
NCC
Gateway
Star coupler
LON-bus
26 relays or control units
Figure 1. System example: 1 star-coupler RER111, 1 monitoring device, 26

relays or control units.
PRG 3DJH
13 / 216 6SHF&/$
$V\VWHPZLWKWZRPRQLWRULQJGHYLFHV
An average size system with local SCS computer and NCC Gateway can be built
with one star coupler if the number of the relays and control units does not exceed
25.
NCC
SCS
Computer
Gateway
Star coupler
LON-bus
25 relays or control units
Figure 2. System example: 1 star-coupler RER111, 2 monitoring devices, 25

PRG 3DJH
14 / 216 6SHF&/$
%LJV\VWHPZLWKPXOWLSOHVXEQHWV
A big system with high data flow requirements can be built so that there are many
subnets which are separated by routers. The monitoring devices contain multiple
LON-bus interfaces and are connected to each subnet.
The big data flow from the relays and control units to the monitoring devices is
divided to many subnets and a monitoring device has many interfaces to handle
the big data flow.
Using three star-coupler of type RER111 a system with up to 67 relays and

control units can be built. (23 in star-coupler 1, and 22 in the next layer star
couplers)
NCC
SCS
GW
Star coupler
LON subnet 1
Star coupler
Star coupler Star coupler

23 relays or control units with Router
with Router
LON subnet 2 LON subnet 3
R SC R SC
22 relays or control units 22 relays or control units
Figure 3. System example: 3 star-couplers RER111, 2 monitoring devices, 67

Note:
In this configuration a domain broadcasted message may arrive to the monitoring

device’s application layer software through all of the LON-interfaces. This
situation must be handled in the higher layer node software.
PRG 3DJH
15 / 216 6SHF&/$
$V\VWHPZLWKLQWHUIDFHWRVWDQGDUGLQGXVWULDO/21QHWZRUN
Interface to twisted pair LON networks are arranged using routers. In this way a
system may be connected e.g. to an industrial control system which has a standard
LON interface or to standard industrial LON devices. This kind of system in
described in the following figure (figure 6).
NCC
SCS NCC
Computer Gateway
Industrial
LON star-coupler control system
Fiber optic LON Router Twisted pair LON
LON/SPA- LON/SPA-
gateway gateway
Protection and Control devices Industrial LON devices
Figure 4. System example: connection to an industrial control system.
In figure 6 there is a star-coupler RER111 with router card. Interface to twisted

pair LON is done via the router. Industrial control system and LON devices are
connected to the twisted pair LON. Interfaces to devices, which have only SPA-
bus interface, is arranged using LON/SPA-gateways.
PRG 3DJH
16 / 216 6SHF&/$
&RPPXQLFDWLRQSURFHGXUHV
*HQHUDO
&RPPXQLFDWLRQFDWHJRULHV
The SCS system is organised in a way that it includes one or more PRQLWRULQJ
GHYLFHV and multiple SURWHFWLRQDQGFRQWUROGHYLFHV. Protection and control
devices may be connected to the LON-bus either directly or via a LON/SPA-
gateway. The system may also communicate with anLQGXVWULDOFRQWUROV\VWHP
and LQGXVWULDO/21GHYLFHVor other “standard” (interoperable) LON devices.
Communication over the LON-bus can thus be classified in the following way:
− vertical communication (communication between monitoring devices and
protection and control devices)
− horizontal communication (communication between protection and control
devices)
− LSG communication (communication with LON/SPA-gateways)
− interoperable communication (communication with interoperable LON
devices)
Each communication category has its own features and some specific
communication procedures and data formats. A device may be configurable so
that it operates in more than one of the communication categories. The event
format may be configurable. The type of used network variables may be
configurable. Also a mixture of these categories in one device is possible. A
device -especially a monitoring device- can support all of the categories
simultaneously.
Vertical communication describes communication between the monitoring

devices and protection and control devices (as defined in chapter 4.3). This
communication includes sending of changed process data to monitoring devices
as events and transfer of commands, parameter data, disturbance recorder files
and configuration files. This communication is implemented using explicit
messages. The format of events and commands is based on [IEC101] definitions.
PRG 3DJH
17 / 216 6SHF&/$
NCC
SCS NCC
Computer Gateway
Vertical Industrial
comm. control system
LON/SPA- LON/SPA-
gateway gateway
Figure 5. Vertical communication.
Horizontal communication describes communication between the protection and

control devices. This communication includes e.g. transfer of interlocking data.
This communication is implemented using network variables.
NCC
SCS NCC
Computer Gateway
Industrial
control system
Horizontal
comm.
LON/SPA- LON/SPA-
gateway gateway
Figure 6. Horizontal communication.
PRG 3DJH
18 / 216 6SHF&/$
LSG communication describes communication used with LON/SPA-gateways.

This includes sending of changed process data to monitoring devices and to other
devices, transfer of commands, parameter data and configuration commands.
This communication is implemented using network variables and explicit
messages.
NCC
SCS NCC
Computer Gateway
Industrial
control system
LSG comm.
in vertical
direction
LSG comm.
in horizontal
direction.
LON/SPA- LON/SPA-
gateway gateway
Figure 7. LSG communication.
PRG 3DJH
19 / 216 6SHF&/$
Interoperable communication describes communication with nodes using protocol

as defined in “LonMark Application Layer Interoperability Guidelines”. This
means use of network variables of standardised types (SNVTs), modelling the
device by using LonMark Objects (node object, sensor objects, actuator objects
and controller objects) and transfer of parameters using network variables or
configuration parameter files.
Examples of this communication could be communication with industrial

automation system which has interoperable LON interface or communication with
commercially available industrial LON nodes.
NCC
SCS NCC
Computer Gateway
Industrial
control system
Interoperable
communication
LON/SPA- LON/SPA-
gateway gateway
Figure 8. Interoperable communication.
PRG 3DJH
20 / 216 6SHF&/$
/RQWDONDSSOLFDWLRQOD\HUSURWRFRO
The application message data formats of the LonTalk protocol can be classified
into two basic types: network variables and explicit messages.
1HWZRUNYDULDEOHV
The LonTalk protocol employs a data oriented application protocol. In this

approach, application data items such as temperatures, pressures, states, text
strings and other data items are exchanged between nodes in standard engineering
and other predefined units. The command functions are then encapsulated within
the application programs of the receiver nodes rather than being sent over the
network. In this way, the same engineering value can be sent to multiple nodes
which each have a different application for that data item.
The data items in the LonTalk application protocol are called network variables.
Network variables can be any single data item or data structure with the
maximum length of 31 bytes.
Network variables are addressed on application level using network variable

selectors. The selector is a 14-bit number in the range 0...12287 (2FFFH).
(Selector values 3000H...3FFFH are reserved for unbound network variables.)
The selector is used a network wide identification of the Network Variable.
Each network variable must be assigned a network variable selector, when system
is configured (this is called binding). This is normally done by a network
management/configuration tool. During configuration the data objects are
addressed using a 8 or 16-bit network variable index.
NV Poll and NV Fetch message are used to poll/fetch a Network Variable. The
message contains either the selector (poll) or index (fetch) of the network
variable.
1RWH All the multi byte structures are sent msb-byte first and lsb-byte as last
byte (in Motorola fashion).
([SOLFLWPHVVDJHV
For applications where data object larger than 31 bytes need to be transmitted,
request/response service is desired, or the network variable model is not suitable,
then the application can use explicit messaging. The application construct
messages containing up to 48 bytes of data (see chapter 4.1.6). These messages
can be explicitly addressed to other nodes using subnet/node, group, broadcast or
unique ID addressing (or they may be addressed to other nodes or groups of
nodes via implicit address connections called message tags.)
Different types of explicit messages are classified using an 8-bit message code. A
special range of message codes is reserved for foreign frame transmission. An
array of bytes of data may be embedded in a message packet and transmitted like
any other message. The LonTalk protocol applies no special processing to
foreign frames - they are treated as a simple array of bytes. The application
program may interpret the data in any way it wishes.
PRG 3DJH
21 / 216 6SHF&/$
Some of the messages codes are reserved for LonTalk Network Management and
Diagnostic services. So called "Foreign messages/responses" can be sent using
messages codes 40H...4FH.
PRG 3DJH
22 / 216 6SHF&/$
7UDQVSRUWVHUYLFHVDQGDGGUHVVLQJSRVVLELOLWLHVSURYLGHGE\/RQ7DON
SURWRFRO
The following transport/session layer services are possible in the protocol:

- acknowledged service
- unacknowledged-repeated service
- unacknowledged service
- request-response service
The following addressing possibilities are specified in the protocol:
- unicast to a node, destination addressed by subnet number and node number
- broadcast to a domain, destination addressed by subnet number = 0
- broadcast to a subnet, destination addressed by subnet number = 1...127
- multicast to a group, destination addressed by group number = 0...255
In all of the addressing formats a domain id of 1, 3 or 6 bytes may be used or it

may be left out.
1RWH Domain id is not needed/used in Substation Automation applications.
The addressing limits given by the message formats and implementation

limitations in the Neuron chip are the following:
Maximum number of nodes per subnet = 127 (node number 1...127)
Maximum number of subnets per domain = 255 (subnet number 1...255)
Maximum number of nodes in a domain = 32385
Maximum number of domains where a node can belong = 2
Maximum number of groups in a domain = 256 (group number 0...255)
Maximum number of members in a group = 64 (group member id 0...63)
Maximum number of groups where a node can belong to = 15
Maximum number of address table entries* in a node = 15 (entry index 0...14)
1RWH The number of address table entries within the Neuron chip is limited to
15. Address table can be extended in nodes which have a separate host processor
and they use Neuron chip only as a communication processor with MIP (or in
nodes using SLTA as network interface). But in this case only 15 first entries can
be used for group addressing, because the group addressing is always handled by
the Neuron chip and not by the attached host.
PRG 3DJH
23 / 216 6SHF&/$
6HUYLFHW\SHVDGGUHVVLQJIRUPDWVDQGWLPHUYDOXHV
The following figure shows transactions diagrams of different message types.

Transaction diagrams for events used in vertical communication can be found in
chapter 4.3. More detailed transaction description can be found in [LPS].
The (default) timer values for different messages types can be changed project
and application based.
NV Éxplicit message (code 41H)

NV with SPA request (R or W)
Éxplicit message (code 40H)
with LSG event
NV
ack ack
NV ack
repetitions
Explicit message (code 41H)
NV sent with NV with SPA reply (D, A or N)
ackd service
Transfer of LSG events
ack
NV sent with unackd_rpt service
Éxplicit message (code 43H) Transfer of transparent

with LSG config. command SPA-bus message NV poll/NV fetch
request message
NM request message
ack
message NV poll/NV fetch
response message
NM response message
Explicit message (code 43H)
with LSG config. reply
NV poll or NV fetch
ack NM message sent with Clock sync message message sent with
request/response service sent with unackd service request/response service
Transfer of LSG Note: Messages marked with “ack” in these pictures

configuration commands mean LonTalk protocols TPDU type 2, acknowledgement.
Figure 9. Transaction diagrams for different message types.
PRG 3DJH
24 / 216 6SHF&/$
1HWZRUNYDULDEOHQDPLQJFRQYHQWLRQV
The following network variable naming conventions are used in this paper.
Each network variable has a type number and a name as follows:

- If network variable is a SNVT then the number (e.g NV type 83) and the name
(e.g SNVT_state) of the standard type are used, the name starts with letters
“SNVT”.
- If network variable is an ABB specific type, then the number is given starting
from 255 downwords (e.g NV type 255) and the name starts with letters “NV”
(e.g. NV_clock).
0HVVDJHOHQJWK
0D[LPXPOHQJWKRIPHVVDJHXVHGRQ/21EXV
We recommend that the maximum number of message data bytes used on LON-
bus messages is 48 bytes.
Maximum length of APDU (Application Protocol Data Unit) is 49 bytes, because
APDU contains message code byte and data bytes. (See appendix 2).
With max. messages length of 48 bytes the max. length of communication

buffers, which is required in the nodes is 66 bytes
%DFNJURXQG
The maximum length of message is limited due to the following reasons:

- LonWorks Network is optimised for short messages
- the default size of communication buffers in most of the LonWorks nodes is 66
bytes
- in RER111 routers the maximum buffer length is 66 bytes
- 66 bytes per communication buffer, allows the use of 3120 chip as the
communication processor
- long messages can always be sent by splitting the message in pieces of max. 48
bytes
- LonTalk file transfer protocol (which splits data into packet of 32 bytes) can be
used to send long strings and files
PRG 3DJH
25 / 216 6SHF&/$
/RQ7DONILOHWUDQVIHUSURWRFRO
This file transfer method breaks up data files into packets containing 32 bytes of
data and transfer packets sequentially. The set up of a file transfer is implemented
with network variables of standard type (SNVTs). The actual transfer itself is
implemented with explicit messages, using a windowed protocol. Most data
packets are sent with unacknowledged service with a request/response packet sent
every sixth packets. These five unacknowledged packets and the sixth
request/response packet constitute a data window. The message code used for file
transfer is 3EH (62). The performance of this protocol is about 2 kilobytes per
second.
Specification of the file transfer protocol can be found in [FTLW].
The LonTalk file transfer protocol defines three roles for file transfer: initiator,
sender and receiver. In substation automation applications files are normally not
sent spontaneously from protection and control devices to the monitoring device
but instead files are transferred when requested by one of the monitoring devices.
The monitoring device which requests the file transfer is the initiator and the
other device is either file sender of receiver.
3UHGHILQHGQYLQGH[HVDQGVHOHFWRUYDOXHV
Substation automation products use the conventions with file transfer related
network variables described in Appendix 3.
If a device has reserved these NV indexes and selector values for file transfer
SNVTs, then the only thing a monitoring device has to know to start file transfer
is the node address of the device (no binding of network variables has to be done
before starting the transfer).
When transferring a file from/to a foreign device the network variables reserved
for file transfer have to be bound before the actual file transfer can start.
PRG 3DJH
26 / 216 6SHF&/$
)LOHGLUHFWRULHV
LonTalk file transfer protocol’s file directory information
During the LonTalk file transfer a file is identified with a 16 bit file index. To get
more information about a file before starting the file transfer a file directory
lookup can be done. The file directory lookup command returns 16-bit file type,
32-bit file size and a 16-character file information string corresponding to the
given file index.
Note: File index 0 is reserved for LonMark Configuration Parameter Template

File, and file index 1 is reserved for Configuration Parameter Value File. (See
[LALI]).
PRG 3DJH
27 / 216 6SHF&/$
$%%DSSOLFDWLRQSURWRFRO
,QWURGXFWLRQ
An ABB specific application protocol on top of the LonTalk protocol is used for
different types of Information (e.g Events, Commands) to have an acknowledge
protocol service for LON Applications. The information is transferred using
explicit messages with unacknowledged transport service of the LonTalk
protocol. The ABB special session protocol and sliding window transport
protocol have been built on top of the LonTalk protocol’s application layer.
(Note: LonTalk protocol’s own transport or session protocol has not been
changed.)
In the following text the devices of the substation automation system are called as
follows:
- clients: monitoring devices, which receive events
- servers: bay level devices, which produce events
The main ideas are:

- each client builds a session connection and sets up the event session to each
server from which it wishes to receive events
- after the session is set up the, servers may start to send events to the client using
sliding window protocol
The session connection, which is opened by a client device, is a bi-directional

connection. Server sends events to the client and the client sends commands (e.g.
ES and GI) to the server using the same connection. All the time-out and
acknowledgement procedures of the sliding window protocol are implemented
both in the client and in the server.
The adressing scheme for the application protocol is used as described in 5.4.2.5
PRG 3DJH
28 / 216 6SHF&/$
The following text serve as introduction to the main operation principles of the
used session protocol and sliding window transport protocol:
• the client opens the session connection using session connection request
TPCU message
• the server stores the subnet/node number of the client and some other data
describing the connection to memory and replies with a session connection
accept TPCU or in special case a session connection reject TPCU message
(see messages chapter 5.7.2.2)
• TPCU TranAck messages are sent to confirm the previously sent messages
• the client opens the event session by sending TPDU data command using
event ES (Event setup, types defined in chapter 5.4.4.2.1.10) and cause of
transmission is 6 (activation).
• the server replies with TPDU data command using event ES (Event setup
response) and cause of transmission (cot) for positive acknowledge is cot=21
+ PN=0 or for negative acknowledge cot=21 + PN=1 or cot =22 in special
case.
• after this the server may start sending TPDU events
• the number of events allowed to be sent, before waiting for an
acknowledgement, was defined in the session connection phase by the client
using TPCU TranAck message where embedded “credit” field gives this
information
• when a certain number of events is sent (credit becomes to zero) the server
must wait for an acknowledgement TPCU message (TranAck) from the client
and from that message it gets new credit from the client
• after setting up the event session the client may update its database by
requesting the latest values of the most important data values in the server’s
database using a TPDU data command event GI (General Interrogation)
message
• the server cannot rely on a GI to start sending Events to the client
• when there is nothing to be sent TPCU TranAck messages are cyclically sent
both by the server and by the client to keep the session connection alive
• when the client wishes to stop the server from sending events it close the
event session by sending ES close cmd.
The details of the messages and the protocol are described later in the text.
_________________________________________________________________
______________
Additional terminology:
Session Protocol: A set of rules to establish and maintain a session. The session
layer will establish and monitor connections and dataflow. Server and client
restart and similar topics are left to the session layer.
Transport Protocol: A protocol used to ensure reliable data transfer between

transport entities in a network. The transport protocol used is a property of the
connection , and should not be visible to the application layer.
PRG 3DJH
29 / 216 6SHF&/$
Sliding Window Protocol: A sliding window protocol is a transport protocol used

to ensure reliable data delivery with relatively little overhead. A sequence number
is assigned to each message, and the recipient will acknowledge proper reception
of data identified by the sequence number. Acknowledge is not needed for each
message as a number of messages may be outstanding. The window is the range
of sequence numbers that may be transmitted without a new ACK. When an ACK
is received, the window is moved so that it starts on the sequence number
embedded in the ACK message. If a message is lost, a NACK should be
generated, and the sender will reposition the window and set the sendpointer to
the first message in the window.
Credit Scheme: In a credit scheme the window size is controlled by the receiver.
A new window size is embedded in the ACK/NACK message.
PRG 3DJH
30 / 216 6SHF&/$
6LJQDO0HVVDJH'HVFULSWLRQ
TPDU Transport Protocol Data Unit
A message with transport control information and some other higher layer
information. These messages will have a sequence number, and the Transport
Provider will retransmit the message until it is acknowledged.
TPCU Transport Protocol Control Unit
A message with transport control information only. These messages are volatile,
and will not be retransmitted if lost.
s-conn.req (TPDU)
A signal from initiating session to remote session provider that a new session is
being requested.
s-conn.res (TPDU)
A signal from responding session provider to requesting session that session was
established or rejected. Also used to indicate a session shutdown initiated from
remote session or application.
conn.req (internal)
A signal from application to session-layer to create a new session.
conn.ind (internal)
A signal from session to application that inform the application about a new
session establish request. The receiving application should reply with a FRQQUHV
or GLVFRQQHFWUHT
conn.res (internal)
A signal from application to local session that the application will serve the new
requested session.
conn.con (internal)
A signal from session to application that the FRQQUHT has been honoured by the
remote session provider. Session is ready to accept data on the channel.
disconnect.req (internal)
A signal from application to session to initiate a session closedown. Session will

generate a
VFRQQUHVin response to request.
disconnect.ind (internal)
A signal from session to application to notify the application about session

closedown. Session closed because a VFRQQUHV with 6HVV1DFN is received from
remote session provider.
PRG 3DJH
31 / 216 6SHF&/$
6HVVLRQ3URSHUWLHV
A Session exist for each client/server instance pairs. The session implements a
bi-directional, safe and monitored data channel between the applications.
• $IXOOGXSOH[VDIHYLUWXDOFLUFXLWWRWKHUHPRWHQRGH
Session control and user Data in either direction will be encapsulated within a
TPDU frame, and the Transport protocol will retransmit all TPDU’s until
acknowledged.
• 6HVVLRQVXSHUYLVLRQ
When the keep-alive mechanism of the protocol detect a channel breakdown, the
session provider will will cause the session to be terminated and a GLVFRQQHFWLQG
will be delivered to the application layer and to the opposite node.
• 8VHUFRQWUROOHGVHQGDQGUHFHLYHTXRWD
The application control the maximum number of queued, outbound messages.

This is called the send quota. The receiver window size is controlled by the
number of available receive-buffers. The receive buffers is assigned to the
Session.More than one session may be active between a pair of nodes. The
dataflow in the sessions are completely independent of each other, and no
relationship whatsoever apply.
PRG 3DJH
32 / 216 6SHF&/$
1HWZRUN73'873&8IRUPDW
Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0

Mtype AppDir SessNack SessAck SessConn TranSeq TranNack TranAck TranData
WinId
SeqNo
Credit
DATA
Session Information Block
$SS'LU 0 = Message from initiator to responder ( Client, control direction )

1 = Message from responder to initiator ( Server, monitor direction )
6HVV1DFN
If SessCon = 0: Field content void.
If SessCon = 1: This is a s-conn.reject or s-disconn.req message
6HVV$FN
If SessCon = 0: Field content void.
If SessCon = 1: This is a s-conn.accept message
6HVV&RQQ
0 = Message is not a session control message.
1 = Message is a session control message, session start type message
Transport Information Block

7UDQ6HT
If TranData = 0: Field content void.
If TranData = 1: Message sequence broken. Accept sequence number
7UDQ1DFN
If TranData = 0: This is a negative acknowledge. Retransmit message which number is in 6HT1Rfield
If TranData = 1: Field content void.
7UDQ$FN
If TranData = 0: This is a positive acknowledge. OK up to 6HT1R
If TranData = 1: Send ACK immediately.
7UDQ'DWD
0=Message is a TPCU ( Ack or Nack )
1=Message is a TPDU ( Data or session control )
WinId
If AppDir = 0: Window identifier in transmitting entity
If AppDir = 1: Window identifier in receiving entity
SeqNo
If TranData = 0:
If TranAck = 1: (Accepted sequence number+1) MOD 256.
If TranNack = 1: (Expected sequence number) MOD 256.
If TranData = 1:
(Message sequence number) MOD 256.
Credit
TranData = 0: Credit. New receiver quota. Send message with sequence number less than SeqNo+Credit.
PRG 3DJH
33 / 216 6SHF&/$
6HVVLRQ3URWRFRO
The connect phase is initiated by the monitoring device. This is of no importance

to the protocol and data flow, and the term initiator and responder is used to
identify their session-protocol role, rather than their application functionality.
Client Transport Server

Session Bus Session
conn.req
s-conn.req
conn.ind
conn.res
s-conn.res(Ack)
conn.con
Figure 10. Session Established Successfully

Session Bus Session
conn.req
s-conn.req
conn.ind
disconnect.req
s-conn.res(Nack)
disconnect.ind
Figure 11. Server application refused to accept request
PRG 3DJH
34 / 216 6SHF&/$

Session Bus Session
conn.req
s-conn.req
Tconn
disconnect.req
s-disconnect.req
Figure 12. Session closed due to connect response time-out

Session Bus
Session
conn.req
s-conn.req
conn.ind
conn.res
s-conn.res(Ack)
conn.con
disconnect.req
s-conn.res(Nack)
disconnect.ind
Figure 13. Session disconnect requested from application after connection

established
PRG 3DJH
35 / 216 6SHF&/$
C lie n t T ra n s p o rt S e rv e r
S e s s io n S e s s io n
c o n n .r e q
s - c o n n .r e q
c o n n .in d
s -c o n n .re s (A c k )
c o n n .re s
c o n n .c o n
Tconn
d is c o n n e c t .in d
d is c o n n e c t. r e q d is c o n n e c t .in d
Figure 14. Session closed due to channel time-out.
PRG 3DJH
36 / 216 6SHF&/$
7UDQVSRUW3URWRFRO
The Transport Protocol is a set of rules to obtain two sets of functionality:
4.1.8.6.1 Data integrity
Messages may be lost due to buffer contention in receiving entity or severe media
contention. Lon implements a very simple transport protocol with the following
qualities:
- Very high network load. Ack must be generated for each message.
- Loss detection only and very limited retransmit functionality.
- Minimal flow control.
The cure for this is to implement a transport protocol on top of the LonTalk
application layer. The protocol to be used has the follwing features:
• 6OLGLQJZLQGRZ
A number of messages may be transmitted without additional network traffic. A

single ACK messages may acknowledge more than one message. This cause
much less network load.
• 'XSOLFDWHGHWHFWLRQ
If a message is duplicated in the network, the sequence number of the message

will less than the one expected, and the message will be discarded. The receiver
may silently ignore the message if it is able to detect it as a duplicate, or it may
generate a NACK if it is unable to identify it as a duplicate or out-of-sequence
message.
• /RVVGHWHFWLRQ
If a message is lost, the sequence number will be larger than the one expected.
The receiver will send a NACK whith requested sequence number.7KHUHFHLYHU
PD\NHHSWKHPHVVDJHDQGUHLQVHUWLWLQWKHLQSXWVWUHDPZKHQWKHORVWPHVVDJH
KDVEHHQGHOLYHUHG7KLVLVQRWPDQGDWRU\DVWKHHQWLUHPHVVDJHVHTXHQFHZLOOEH
UHWUDQVPLWWHGLQQHFHVVDU\.
• 5HVHTXHQFLQJ
All messages have a sequence number, and the messages are guaranteed to be
delivered in correct order7KHUHFHLYHUPD\LPSOHPHQWUHVHTXHQFLQJEXWWKLVLV
QRWQHFFHVVDU\IRUWKHSURWRFROWRZRUN
• )ORZ&RQWURO
The active window size is controlled by the Transport User ( ie

Session/Application) with a Credit field in the TPCU messages. The Credit is
decremented as receiver buffer space is consumed, and incremented as new
buffers are assigned to the transport provider. This flow control will be end-to-
end.
PRG 3DJH
37 / 216 6SHF&/$
4.1.8.6.2 Data flow control
Transmit off sequence

• Receiver transport consume buffers and reduce Credit
• Credit become 0, and zero-credit ACK/NACK is sent by receiver transport.
• Send window is exhausted, and no new messages will be sent.
• Transmitter output queue become full, as session has limited send-quota.
• Application fail to send new messages as send-quota exceeded.
Transmit on sequence
• Receiver application grant new receive quota to receiver transport.
• Credit become non-zero and receiver tranport send non-zero credit ACK/NACK message.
• Transmitter transport receive ACK/NACK and send first message in output-stream.
• Receiver transport receive message and send ACK.
• Transmitter transport discard message copy and get send-quota.
• Transmitter transport send write.ind to application because send-quota
granted.
• Transmitter application generate more output data.
Flow Recovery.
Transmitter Recovery
The first unacknowledged message will always have a retransmit timer running. When the
timer expire, a credit of 1 will be generated internally and the message will be transmitted.
If receiver transport is now able to handle message, a normal ACK with new credit will
be generated.
If receiver transport is still unable to handle message, the receiver tranport may choose to
send a zero-credit NACK or to do nothing.
Receiver Recovery.
The receiver must send ACK or NACK cyclic to keep the channel alive. If a non-zero credit
ACK is lost, the next one may success.
PRG 3DJH
38 / 216 6SHF&/$
4.1.8.6.3 Transmitter Procedures
Application data send
&KHFNWUDQVPLWWHUTXRWD
Return error if transmitter quota exceeded. This is neccessary to implement the end-to-end flow
control. Transmitter quota should be larger than maximum credit to ensure backpressure on
channel. Without backpressure the application must generate new data after each ACK, and
the control flow become more complex.
$SSHQGPHVVDJHWRRXWSXWTXHXH
Allocate a new sequence number for the message and link it into the list of pending messages. If
this is the oldest message (no transmitted messages with pending ACK and no other
pending messages) do restart retransmit timer (Tretr). This must be done to enable
transmitter flow recovery after lost non-zero ACK.
*HWILUVWSHQGLQJPHVVDJHIURPTXHXH
• Seqeunce number in <oldest.seqno> - <oldest.seqno + Credit -1 > range.

• Set TranAck flag if this is last with current credit. This is neccessary to force an ACK
from receiver when message is received. Without this flag the receiver will not send
ACK until the Ack-Push timer has expired, a situation which will cause severe
performance degradation
• Send message as credit available.
• Compute retransmit timeout for message.
• Set first pending to next pending
• Goto 3
• No more pending messages available or
• Sequnce number outside <oldest.seqno> - <oldest.seqno + Credit -1 > range.
• No further action as dataflow or message loss prevent new messages from being
accepted in receiver transport.
Cyclic
• &KHFNFRQQHFWLRQWLPHU
• 7LPHRXWUHDFKHG
Return all messages and buffers to global pool.
Generate a disconnect.ind to session provider as the connection is closed.
• &KHFNUHWUDQVPLWWWLPHURIROGHVWPHVVDJH
• 7LPHRXWUHDFKHG
This timeout may have two possible reasons.
• Message has not been transmitted because of flow-control
• Message has been transmitted but not ACK’ed within time-slot.
5HJDUGOHVVRIUHDVRQWKHIROORZLQJVWHSVVKRXOGEHWDNHQ
• Set first pending to oldest message.
• Set Credit to 1
• Set TranAck flag for oldest ( = pending ) message.
• Send oldest (=pending) message.
• Compute retransmitt timeout for message.
• Set first pending to next pending.
• 7LPHRXWQRWUHDFKHG
No further action
PRG 3DJH
39 / 216 6SHF&/$
TranAck received
• 5HVHWFRQQHFWLRQWLPHU
• 'LVFDUGDOOPHVVDJHVZLWKVHTXQFHQXPEHUOHVVWKDQ7UDQ$FN6HT1R!
*HWILUVWSHQGLQJPHVVDJHIURPTXHXH
• 6HTXQFHQXPEHULQROGHVWVHTQR!ROGHVWVHTQR&UHGLW!UDQJH
• Set TranAck flag if this is last with current credit. This is neccessary to force an ACK
from receiver when message is received. Without this flag the receiver will not send
ACK until the Ack-Push timer has expired, a situation which will cause severe
performance degradation
• Send message as credit available.
• Set first pending to next pending
• Goto 1.
• 1RPRUHSHQGLQJPHVVDJHVDYDLODEOHRU
• 6HTXQFHQXPEHURXWVLGHROGHVWVHTQR!ROGHVWVHTQR&UHGLW!UDQJH
• No further action as dataflow or message loss prevent new messages from being
accepted in receiver transport.
• Generate indication to application if send-quota EHFDPH non-zero.
Reason for this is to reactivate application which may have stopped transmitting due to flow
control.
PRG 3DJH
40 / 216 6SHF&/$
TranNack received
• 5HVHWFRQQHFWLRQWLPHU
• 'LVFDUGDOOPHVVDJHVZLWKVHTXQFHQXPEHUOHVVWKDQ7UDQ1DFN6HT1R!
A negative acknowledge is also a positive acknowledge for all messages with sequence numbers
below the NACK’ed sequence number.
• Set first pending to oldest message.
• Set Credit to 1
• Set TranAck flag for oldest ( = pending ) message.
• Send oldest (=pending) message.
• Set first pending to next pending.
• Generate send-quota available message to application if send-quota EHFDPH non-zero.
Reason for this is to reactivate application which may have stopped transmitting due to flow
control.
PRG 3DJH
41 / 216 6SHF&/$
4.1.8.6.4 Receiver Procedures
In this chapter there are a few program states abbreviations used to help reader to understand
different situations. Here is short decsriction of the program states:
IN_SEQ = This means that the message receiced is in right position in the
message stream. So in this situation no errors are occured.
IN_ERR = This means that the message receiced caused an error. The sequence
number in a message was not in line with previous received messages. Now the
receiver program is in error state.
IN_IDLE = This means that the message receiced is in right position in the
message stream but there has not been any data messages in the bus for
awhile.This message is part of keep alive mechanism and the receiver program is
in this state when the receiver has not received any data messages after last
acknowledged messsage.
Grant receive quota
• Increment <Credit> as Application/Session has granted the transport layer a new receive-quota
unit. The <Credit> is always the number of available quota-units. A quota-unit represent a
buffer or the right to allocate and consume a buffer. The actual handling of this is of course
implementation specific.
• If Credit was 0
• if state = IN_SEQ or IN_IDLE
• generate an ACK(expected,Credit)
• recompute Tseq ACK-push timer
• if state = IN_ERR
• generate a NACK(expected,Credit)
• recompute Terr ACK-push timer
• Deliver first message from input-queue.
TPDU Received.
Allocate receive buffer from granted buffer quota. Implementation of resequncing is not descibed
here.
• $OORFDWHEXIIHU2.
• Read message from network.
• Decrement Credit property of receiver transport entity.
• 0HVVDJHVHTXHQFHQXPEHU2.RU73'87UDQ6HT!IODJVHW
• Append message to input-queue
• Check if <TPDU.TranAck> flag set
• Set.
• Send ACK(expected,Credit)
• Compute new Tseq ACK-push timer
• set state = IN_SEQ
• Clear.
• If state = IN_SEQ or IN_IDLE
• If state = IN_ERR
PRG 3DJH
42 / 216 6SHF&/$
• Deliver all messages in input queue to application

• 0HVVDJHVHTXHQFHQXPEHU!H[SHFWHG
• Discard message buffer and increment Credit
• Send NACK(expected,Credit)
• Compute new Terr ACK-push timer
• set state = IN_ERR
• Discard message buffer and increment Credit
• )DLOHGWRDOORFDWHEXIIHU
• Set Credit = 0
• Send NACK(expected,Credit=0)
• set state = IN_ERR
• No action. Do not send NACK, as a NACK already sent and new NACK will be
generated cyclic by poll routine.
Cyclic
• if Tseq timer expired

• Send NACK(expected,Credit)
• if after 5 cycle times in state „IN_ERR“ go into state „IN_IDLE“
• If state = IN_SEQ
• set state = IN_IDLE
• If state = IN_IDLE
• Compute new Tidle ACK-push timer
• set state = IN_IDLE
PRG 3DJH
43 / 216 6SHF&/$
4.1.8.6.5 TPDU / TPCU flow diagrams
6HUYHU &OLHQW
ACK(SeqNo=1,Credit=5)
01
FromServer application
produced events
Client grant credit

06 after each message
TPDU(SeqNo=1)
is passed to the application
01
Conf (1)*
02
Conf(2)
03
Conf(3)
04
TPDU(SeqNo=5,TranAck=1) Conf(4)
05
Server releases Conf(5)
buffers after ack. ACK(SeqNo=5,Credit=4)
msg fromreceiver
01
TPDU(SeqNo=6)
04 06
Tseq Conf(6)
05
06
Tidle
keep session alive mechanism
* conf(x) = confrimfromthe application, due to the philosophy

not to lose the data until the client application received it
Figure 15. Normal message flow. No messages lost. No Ack lost.

More than <Credit> messages available.
PRG 3DJH
44 / 216 6SHF&/$
6HUYHU &OLHQW
ACK(SeqNo=1,Crd=5)
TPDU(SeqNo=1)
01
02
03 01
Conf(1)
04 02
Conf(2)
05
TPDU(TranAck=1) 04
Client rejects
05 wrong msgs
NACK(SeqNo=3,Crd=5)
01 TPDU(SeqNo=3,TranAck=1)
03
02
Conf(3)
ACK(SeqNo=3,Crd=4)
TPDU(SeqNo=4)
04
Conf(4)
06 05
TPDU(SeqNo=6) 06
Tseq
Keep session
alive mechanism
Keep session
live mechanism ACK(SeqNo=5,Crd=3) Conf(5)
Conf(6)
03 ACK(SeqNo=1,Crd=5)
04
Tidle
Tidle Keep session

Keep session alive mechanism
live mechanism ACK(SeqNo=7,Crd=5)
05
ACK(SeqNo=1,Crd=5)
06
Conf(x) = confirm from the application, due to the philosophy

not to lose the data until the client application received it
Figure 16. A single message Lost. Keep alive mechanism working in both
direction.
PRG 3DJH
45 / 216 6SHF&/$
6 H UY H U & OLH Q W
A C K (S e q N o = 1 ,C rd =5 )
01 T P D U (S e q N o = 1 )
02
03 01
C o nf(1)
04 02
C o nf(2)
05 03
C o n f(3 )
04
T P D U (S e qN o = 5 ,T ra n A ck= 1 ) C o n f(4 )
05
C o n f(5 )
06
T retr A C K (S e q N o = 5 ,C rd =4 )
T P D U (S e q N o = 1,T ra nA ck= 1 ) M sg alre a d y

01
h a n dled by re ceiver
S e rve r re le a se s
N A C K (S eq N o = 6 ,C rd= 5 )
b uffe rs a fter a c k . 01
m sg fro m clie n t
05
T P D U (S e q N o = 6 )
06
C o n f(6 )
T se q
A C K (S e q N o = 7 ,C rd =5 )
06
Figure 17. A single ACK lost. More than <Credit> messages available.
PRG 3DJH
46 / 216 6SHF&/$
6 H UY H U & OLH Q W
A C K ( S e q N o = 1 ,C r d = 5 )
T P D U (S e q N o = 1 )
01
02
03 01
04 02
C o n f.( 0 1 )
05
04
T P D U ( S e q N o = 5 ,T ra n A c k = 1 )
05
N A C K ( S e q N o = 2 ,C rd = 4 )
T e rr
N A C K ( S e q N o = 2 ,C rd = 4 )
01 C lie n t a lr e a d y
T P D U ( S e q N o = 2 ,T ra n A c k = 1 ) h a n d le d m s g
02
A C K ( S e q N o = 2 ,C r d = 4 )
06 03
04
T P D U ( S e q N o = 6 ,T ra n A c k = 1 ) 05
06
A C K ( S e q N o = 2 ,C r d = 0 )
07
T r e tr
M s g r e je c te d b e c a u s e
th e r e is n o m o r e fre e
T P D U ( S e q N o = 7 ,T ra n A c k = 1 ) b u ffe r s a v a ila b le
07
N A C K ( S e q N o = 2 ,C rd = 0 )
C o n f( 0 2 )
A C K ( S e q N o = 3 ,C r d = 1 )
02 T P D U ( S e q N o = 3 ,T ra n A c k = 1 ) C o n f( 0 6 )
03
N A C K ( S e q N o = 7 ,C rd = 5 )
03 T P D U ( S e q N o = 7 ,T ra n A c k = 1 ) 07
A C K ( S e q N o = 7 ,C r d = 4 )
Tseq
A C K ( S e q N o = 8 ,C r d = 5 )
07
Figure 18. a. Message Lost. b. NACK lost. Receiver quota exceeded.
PRG 3DJH
47 / 216 6SHF&/$
6HUYHU &OLHQW
ACK(SeqNo=1,Crd=5)
01 TPDU(SeqNo=1)
02
03 01
04 02
05 Conf (01)
TPDU(SeqNo=5,TranAck=1)
Tseq
06
ACK(SeqNo=2,Crd=4)
Conf (02)
Tret
TPDU(SeqNo=1,TranAck=1)
01
NACK(SeqNo=3,Crd=5)
01 TPDU(SeqNo=3,TranAck=1) 03
02
ACK(SeqNo=3,Crd=4)
Conf (03)
TPDU(SeqNo=4)
TPDU(SeqNo=6) 04
05
06
Conf (04)
ACK(SeqNo=7,Crd=5)
03
04
05
06
Figure 19. Cable break down, many messages lost. Recovery situation.
PRG 3DJH
48 / 216 6SHF&/$
4.1.8.6.6 Transport protocol timers
Connection Timer Tconn

The connection timer is maintained to monitor the operation of the remote node.
On an active channel there will be a lot of traffic, and on a idle channel a low
frequency keepalive transmission is going on. The receiver will send an ACK or
NACK message at least every <Tidle> mSec. The connection timeout Tconn
should be in the range of 1 minute. Default value for this timer is 60000 mSec.
Retransmitt Timer Tretr

The retransmission timer is activate for the oldest unacknowledged message. It is
used to trigger a retransmission of the message if the message or the ACK/NACK
was lost. The Retransmit timer must be larger than the time it take to send a full
window (max Credit). Default value for this timer is 5000 mSec.
Tseq Timer
The Tseq timer control the time the receiver wait after it receive a message before
it send an ACK. This timer is restarted for every received message, and will only
time-out when the channel is idle. Under high traffic periods, the sender will
exhaust the Credit and flag the message for immediate ACK ( TranAck flag). In
such circumstances the Tseq timer will not expire. Default value for this timer is
300 mSec.
Terr Timer
The Terr timer control the cyclic sending of NACK after a message sequence
error. This timer is only active when network congestion occur, and should be in
slightly less that Tretr-Timer. Default value for this timer is 750 mSec.
Tidle Timer
The Tidle timer is used to keep channel alive and to retransmitt an ACK’s in case
of ACK loss. The flow will driven by the Tretr in case of ACK loss, so this need
only be smaller than Tconn. Default value for this timer is 10000mSec.
PRG 3DJH
49 / 216 6SHF&/$
+RUL]RQWDOFRPPXQLFDWLRQ
Horizontal communication describes communication between the protection and

control devices. This communication includes e.g. transfer of interlocking data.
This communication is implemented using network variables.
*XLGHOLQHVIRU19ELQGLQJ
Guidelines for the binding of network variables. In principle only network

variables of the same type are allowed to be bound together. There are some
exceptions to these rules, when one type of source may be bound to more than
one type of sink and vice versa (NV_bit_write and NV_control may both be
bound to NV_state). In these cases it is necessary that both sides know the
definitions of the bound network variables. The table below defines what
connections are allowed on the LON bus.
No NV Source type NV sink type LSG source LSG sinks

1 1-bit value in SNVT_state 1 LSG DO BIN LSG DI BIN
4 Hex value in SNVT_state 4 LSG DO HEX LSG DI HEX
5 NV_control 3, 5 LSG DO BIN Command LSG DI BIN
6 NV_bit_write (BWR) 3 LSG DO BWR LSG DI BIN
7 NV_32b_analog 7 LSG AI (SRIO) AI
8 NV_16b analog 8 LSG DO DEC LSG DI DEC
9 NV_clock_warning 9 (SRIO) NV_clock_warning NV_clock_warning
10 NV_clock 10 (SRIO) NV_clock NV_clock
11 NV_sync_time 11
12 NV_time 12
13 NV_t_data 13
The source and sink types are the NV types as defined in this paper, chapters 5.5
and 5.6. The LSG source and LSG sink are the type names used in the description
of the LON SPA Gateway and SRIO1000.
$OORFDWLRQRI3ULRULW\VORWV
Priority should only be used by NV when exchanging time critical data. For all
vertical communication (events, disturbance recorder data etc.) priority should not
be used.
For the allocation of priorities on the LON bus the following 3 rules must be
applied:
1. The highest priority slot is reserved for tools temporarily connected to the bus.
This will prevent that a continuously sending unit with priority shall block the bus
for a tool.
2. For NV data exchange between units with distributed applications having high
demands on availability of the communication media and short response times the
next higher priorities shall be distributed, one priority slot per unit.
PRG 3DJH
50 / 216 6SHF&/$
3. The unit responsible for the sending the clock synchronising NVs must have a
priority either lower than the units mentioned in 2. or the lowest of the priorities
reserved for the units mentioned in 2. The latter is the case when the unit
responsible for the sending of the clock synchronising NVs also has a distributed
application as described in 2.
&RPPXQLFDWLRQVHUYLFHVIRU19GDWDH[FKDQJH
For data exchange with NV:s any service (unacknowledged, unacknowledged

repeated, acknowledge and request response) may be used, depending on the
application requirements. It is up to the application to make sure that the
application requirements are fulfilled and also that the application has a well
defined upper limit of bus bandwidth usage in order to be able to dimension the
bus parameters/structure as well as calculate the bus performance for a given
communication system. This is important for the engineering phase.
*XLGHOLQHVIRUVHWWLQJ1HXURQFKLSSDUDPHWHUVDQGEXIIHUFRXQWV
With 1.25 Mbits/s network the timer values in Appendix 5 . are recommended.
PRG 3DJH
51 / 216 6SHF&/$
9HUWLFDOFRPPXQLFDWLRQ
*HQHUDO
Vertical communication decribes communication between the monitoring devices

and protection and control devices. This communication includes sending of
changed process data to monitoring devices as events and transfer of commands,
parameter data and files. This communication is implemented using explicit
messages. The format of events are based on [IEC101] definitions.
Chapter 4.1.8 describes communication procedures (session protocol and sliding

window transport protocol), which are used to transfer events (the format of
which is described in 5) to the monitoring devices. Additionally the same
procedures are used to send ES or GI commands from the monitoring devices to
the protective relays or control units.
,QLWLDOL]DWLRQRIWKHHYHQWVHVVLRQV
*HQHUDO
The substation automation system has two categories of devices regarding the
events. The bay level devices that produce events are here called event servers.
The station level monitoring devices that monitor the events are called event
clients. The event server has no pre-configured event clients, i.e. the bay level
devices do not know the system structure of the substation. The event client is
configured to know what event servers are available in the system, i.e. the station
level devices know what bay level devices the system contains.
(YHQWVHVVLRQ
The connection between an event client and an event server is called an event
session. It is always the event client that has the initiative to establish the event
session. The event server dynamically accepts session requests from clients.
However the event server may have a limit of simultaneous event clients that he
supports. When the limit is exceeded the event server should reject session
request of the client. The event server may in addition have other criteria’s for
rejecting event session (see below).
When the bay unit starts up it should not accept event session requests until the
event server is initialised and ready to serve requests by event clients, e.g. general
interrogations. When the event client is started it will try to establish sessions to
the event servers it is configured for. If the client fails to establish a session to a
certain server or if a session dies, e.g. due to communication failures, the client
will periodically try to re-establish the session. The delay between the trials is
configurable.
The event session is kept alive by the event server by sending the event messages.
If no events are produced the event session is kept alive by both event server and
event client according to the description of the transport provider (chapter 4.1.8).
Both server and client may shut down the session.
PRG 3DJH
52 / 216 6SHF&/$
(YHQWILOWHUV
Event filters are used to reduce the event flow to an event client by masking out
events that the event client is not interested in. The event filters are identified by a
number. The event client selects the filter it want’s to use when he establishes the
event session. More than one client is allowed to use the same filter. If a client
want’s to change filter he has to close the event session and start a new one with
the new desired filter number. If a client requests an unknown or not configured
filter the server should reject the event session.
A default filter is identified by number zero (0). All event servers should support
at least the default filter. The event server may be configured to map the default
filter to another filter number. It is recommended that the default filter has the
coarsest mask.
(YHQWKLVWRU\
Optionally the event server keeps a history of unfiltered time stamped events.
Entries in the event history buffer are removed only when the buffer becomes full.
The event server may have different buffers for different event categories such as
measurands, indications and abstract events, in order to prevent “important”
events from sliding out from the event buffer as a result of entries from frequent
event producers (like measurands).
The event client may request “history” events in conjunction with establishing the
event session. History events are events produced (time stamped) before the
session was established. The client selects the length of the history he is interested
in by specifying the time of the oldest event he wants. The messages carrying
history events has a specific cause of transmission (HISTORY). Events from the
history buffer are filtered with the same mask as spontaneous events.
(VWDEOLVKLQJWKHHYHQWVHVVLRQ
The flow of events from server to client is initiated in two steps:
1) The event session is started according to chapter 4.1.8.5. At this stage the
server is not yet allowed to send events to the client.
2) The client sends a ES command to the server. The command carries the
following information:
a.The number of the desired event filter. Number zero (0) is used if no specific
filter is desired.
b.A flag indicating if the event client requests an event history.
c.The time of the oldest event requested in the event history. If no history is
requested the time is void.
PRG 3DJH
53 / 216 6SHF&/$
Server Client
Subscription (Filter, History)

ES command (cause 6)
Accept ES response (cause 21+ PN=0)
History &
Spontaneous events
GI command (cause 6) General Interrogation
Confirm
GI response (cause 7)
GI data
History &
Spontaneous events
GI termination GI response (cause 10)
Figure 20. Establishment of the event session.
Server Client
Subscription
(Filter, History)
ES command
Reject ES response (cause 21+PN=0 or 22)
Figure 21. Establishment of the event session, session rejected by the server.
PRG 3DJH
54 / 216 6SHF&/$
&ORVLQJWKHHYHQWVHVVLRQ
The flow of events from server to client is initiated in two steps:
Before closing a communication session the client shall close the event session
with an ES command (cause of transmission equal to 8). The server may not send
any events after it has received the event session close command. The only valid
answer to the close command is the ES response with cause of transmission equal
to 21 + PN=0. This means that the client will close the session unconditionally
either after that the server responds to close command, or when it consider that
the close command is concidered to have gone into a timeout. Note that the client
must process incoming events until the server responds to the event session close
command (or until close command timeout).
Server Client
Comm session opening

Accept ES response (cause 21+PN=0)
History &
Spontaneous event(s)
GI command (cause 6) General Interrogation

Confirm
GI data
Histrory &
GI termination
ES command (cause 8) Event session close command
ES response (cause 21+ PN=0)

Event session closed
Comm session closing
Figure 22: Closing the event session.
PRG 3DJH
55 / 216 6SHF&/$
*HQHUDOLQWHUURJDWLRQ
General interrogation (GI) is used by the event client in order to get a fresh image
of the objects participating in the event session. The GI is initiated by means of a
parameterless GI command. The GI command may be sent by the event client at
any time when there is an active event session. The event server has to
acknowledge the GI command.
The event server has the knowledge of which objects that are subject to GI. These
objects are generally digital indication objects (single- or double point) or
analogue measurement objects. Following a GI command the objects are sent
successively within the event session using the normal transmission of event
messages. If the event session dies the GI is automatically aborted by the event
server. GI data may be sent without a time tag. The messages carrying
interrogated data are identified by a specific cause of transmission (GENERAL
INTERROGATION). GI data is sent only within the session that requested the
GI.
The event server is allowed to send history and spontaneous events before the
first GI within an event session. Under all circumstances the correct chronological
(except for history events) order of reported data (e.g. events) for a certain object
has to be maintained by the server.
After all objects subject to GI have been transmitted, the event server sends a GI
termination message. If a new GI initiation command occurs within a GI cycle,
the current GI cycle will be aborted without a GI termination message. A new GI
cycle will be started from the beginning. The event client may also abort a
running GI by sending a GI termination command. The GI termination command
is confirmed by the server.
PRG 3DJH
56 / 216 6SHF&/$
6HWXS6HVVLRQ
4.3.2.8.1 Establishing the setup session
A setup session is used as an optional, additional step (if used) between transport
session establishment and setup of an event session.
The flow of information from server to client is initiated in two steps (see Figure
23):
1) The session is started according to chapter 4.1.8.5. At this stage the server is
not yet allowed to send events to the client.
2) The client send a SS command to the server.

The command carries the following information:
• type of setup session information to be transferred.
Server Client
Conn.ind S-conn.req
Conn.req
S-conn.res(Ack)
Conn.res Conn.con
SS command (cause 6)
Session Setup
SS response (cause 7 )
Obj.Hdl-Command (cause 6) Optional

Obj.ind startup
Obj.req
Obj.res Obj.Hdl.-Command (cause 7) sequence
Obj.con
...

GI command (cause 6)
Confirm General Interrogation
GI data
History &
Spontaneous events
GI termination
Figure 23. Establishment of the setup session.
In case no setup session is required the startup sequence is according to 4.3.2.5.
In case of interruption of the startup session (e.g. breakdown of the transport

session) both, client and server must skip the transferred setup information (e.g.
substituted informations). Setup Session will be completely reestablished after
establishment of the transport session.
PRG 3DJH
57 / 216 6SHF&/$
If the server device is configured for a setup session, neither spontaneous events
nor history events nor GI data are transferred from server via any open client
session as long as :
• the setup session has not successfully completed (i.e., been succeeded by an
event setup from setup session client, see 4.3.2.8.2) or
• a timeout for waiting for setup session establishment has not yet expired;
timeoutss-establish value configurable (default 10 min) or
• a timeoutss-finish for supervision of finishing the setup session has not yet
expired; timeout value configurable.
If a server is not configured for a setup session the setup session command
response is negatively confirmed (see Figure 24).
In case a setup session is currently established no other setup session

establishment to another client will be granted by the server (negative response).
In addition, if once a setup session procedure has been established to a server, no

other setup session will be accepted by the server via other connections (negative
response).
Server Client
Subscription
(Filter, History)
SS command
Reject
SS response (cause 7 & PN=1)
Figure 24. Establishment of the setup session, rejected by the server.
If a client receives a negative setup session command response it continues with

normal operation (event setup, see 4.3.2.5) or specified user response.
Also in case no response to a setup session command is received after a timeout

(e.g. older device), the client continues with normal operation.
PRG 3DJH
58 / 216 6SHF&/$
4.3.2.8.2 Closing the setup session
No explicit closing of the setup session is necessary. The setup session is

followed by the event setup (see 4.3.2.5)
4.3.2.8.3 Setup session with multiple clients
The following pictures depict the behavior for setup session with multiple clients.
Only one client is configured for the setup session establishment.
Server (cfg for SS) Client_1 Server (cfg for SS) Client_2
S-conn.req S-conn.req
S-conn.res(Ack) S-conn.res(Ack)
SS command (cause 6) ES command (cause 6)
SS response (cause 7 ) ES response (cause 21+ PN=0)

Session Setup
Obj.Hdl.-Command (cause 6) GI command (cause 6)

Obj.Hdl.-Command (cause 7)
timeout ss-finish
………..
….
wait
Datatrigger
GI data
History &
GI command (cause 6) Spontaneous
events
GI data
History &
Spontaneous GI Termination (cause 10)
events
GI termination (cause 10)
Figure 25: Establishment of the setup session, one server, two clients, normal
operation, client_1 and client_2 same start.
Datatrigger due to finished setup session to send data to other
clients.
The timeoutss-finish is triggered by SS command received by the server via any

session. This timer is used to supervise , if setup session has succesfully
completed. For normal operation this timer does not expire,.i.e after setup session
is finished, GI data with successive spontaneous information will be transfered
via any open session with ES carried out.
If the server receives the ES command, via the session where the setup session
has been carried out, a datatrigger will release sending server data (e.g. GI-data,
history events etc., see Figure 25) to other open client sessions.
PRG 3DJH
59 / 216 6SHF&/$
S-conn.req
S-conn.res(Ack)
timeout ss-establish
S-conn.req GI response (cause 7)
S-conn.res(Ack)
…
SS command (cause 6) wait
Trigger
SS response (cause 7 ) wait (Trigger)
….
...
timeout ss-finish
Datatrigger
GI command (cause 6) GI data
GI response (cause 7) History &

GI data Spontaneous
History & events
Spontaneous
events
GI Termination (cause 10)
Figure 26: Setup session, one server, two clients, client_2 starts first, timeoutss-
establish not expired, trigger of timeoutss-finish for setup session due to
SS command.
Datatrigger due to finished setup session to send data to other
clients
In case a client without setup session (client_2) starts up before a client with setup
session (client_1) the timeoutss-establish is triggered by the ES command.
A successive SS command of client_1 stops timeoutss-establish and triggers a second

timer timeoutss-finish . This timer is used to supervise if setup session has
succesfully completed.
If the server receives the ES command, via the session where the setup session
has been carried out, a datatrigger will release sending server data (e.g. GI-data,
history events etc., see Figure 26) to other open client sessions.
PRG 3DJH
60 / 216 6SHF&/$
S-conn.req
S-conn.res(Ack)
timeoutss-establish
…
expired
GI data
History &
S-conn.req
Spontaneous
S-conn.res(Ack) events
SS command (cause 6) GI Termination (cause 10)
SS response (cause 7 )
Event due to Subst. Cmd
...

GI data
History &
Spontaneous
events
Figure 27: Setup session, one server, two clients, client_2 starts first,
timeoutss-establish expired,
In case a client without setup session (client_2) starts up before a client with setup
session (client_1) the timeoutss-establish is triggered by the ES command.
If the timeoutss-establish expires, before setup session is initialized by the ss

configured client, the server carries on with normal operation (i.e server sends GI
data, history & spontaneous events).
If the server carries on in normal operation and the client with setup session starts,
operates the SS command procedures, the object handling command results (e.g.
substitutions) are transmitted as spontaneous events (see Figure 27).
PRG 3DJH
61 / 216 6SHF&/$
S-conn.req S-conn.req
S-conn.res(Ack) S-conn.res(Ack)
SS command (cause 6) ES command (cause 6)
SS response (cause 7 ) ES response (cause 21+ PN=0)

Session Setup
Subst.-Command (cause 6) GI command (cause 6)

Subst.-Command (cause 7)
………..
….
wait
timeout ss-finish
expired GI data
History &
Spontaneous
events
Figure 28: Setup session, one server, two clients, client_1 start first,
timeoutss-finish expired due to failure of client_1
In case a client with setup session (client_1) starts up before a client without setup
session (client_2) the timeoutss-finish is triggered by the SS command.
If the timeoutss-finish expires due to failure of the setup session from client_1 the
server discards the necessary object handling command changes (e.g. substituted
information must be desubstituted ) and carries on with normal operation (i.e
server sends GI data, history & spontaneous events, see Figure 28) .
If the abnormal condition occur that the setup session client (client_1 )
periodically restart during the timeoutss-finish has not expired this has to be
considered by the server or client :
• The server can limit the max. number of retrigger for the timeoutss-finish .
• The restart of the client for setup session can be extended over the value of
timeoutss-finish .
A Client with configured setup session must supervise completion of setup

session and if the setup session has not completed successfully the client has to
close the transport session and reestablish setup session.
PRG 3DJH
62 / 216 6SHF&/$
To summarize activities of a server configured for setup session, Figure 29

describes the state of the server.
Also the conditions for trigger and resetting the timers and the actions of the
server are described below.
Server States
Server restart
configured for SS
first setup session command Setup session completed sucessfully

Setup session completed sucessfully
(i.e. ES via SS connection received)
or first ES command (i.e. ES via SS connection received)
timeoutss-establish expired
Init Normal
timeoutss-finish expired
timeoutss-finish expired
Init : no GI response via any session and

no spontaneous events via any session
Legend :
Normal : GI response via any session and Transition

Spontaneous events via any session State 1 State 2
Figure 29: State diagram for a server configured for setup session
If a server is not configured for setup session the restarted server will directly go
into normal state and no timers must be handled.
Trigger and reset conditions for both timers are as follows :
a. Trigger conditions
timeoutss-establish : first ES command
timeoutss-finish : Setup session command
b. Reset conditions
timeoutss-establish : SS command after the trigger of a ES command (from
another client)
timeoutss-finish : ES command after SS command (from same client)
Server actions when timer expired :

timeoutss-establish : carry on with normal operation (i.e. GI response, spont.
events to any session)
timeoutss-finish : disregard object handling commnds (i.e if substitutions
were made desubstitute all substituted informations)
carry on with normal operation (i.e. GI response, spont.
events to any session)
PRG 3DJH
63 / 216 6SHF&/$
&RPPDQGKDQGOLQJ
&RPPDQGWUDQVIHU
Command transfer via explicit message over LON is based on [IEC5] (section
6.8).
The features of command transfer via message data are:
• For each command transferred to a bay unit a command reponse is transferred

back to the client, having the same format and the same address as the
command itself (confirmed services: &21, compare 7DEOH).
• The status of the command transfer and acceptance is coded in the CAUSE
OF TRANSMISSION.
• Additional information for the command execution can be given in the

Application Command
Response (ACR) field, which is used by the application in the bay unit
(function block programming, in general).
• The originator address must be mirrored by the server
• The transfer of the information ACTERM from a server is optional and has to
be configurable in the server
The ACTERM generation can be done as follows :
Type Id ACTERM
45 Configurable
46 Configurable
47 Configurable
50 Configurable
51 Configurable
101 Not needed
110 Not needed
228 Not needed
229 Not needed
230 Not needed
• For COT 48, 49 the PN bit is set to 1 (negative) confirmation
• Command responses are transfered with the same address as the command
itself
PRG 3DJH
64 / 216 6SHF&/$
Client Server
Control direction
Command Command (COT= 6,8)
Monitor direction
timeout
Command response Cmd response (COT=7,9,49)
...
Cmd response (COT=10) Acterm (optional)
Command response
Figure 30: Command sequence (Monitor and Control direction)
&RPPDQGVWUDQVIHUHGDV63$0HVVDJH
• The transparent SPA-bus message is an explicit LON message, which contains

an ASCII character message following the coding rules of the SPA-bus
protocol.
• The message is sent using explicit messages with LON message code 41H and
using acknowledged transport service.
• Both the SPA-bus command messages (R or W) and the reply messages (D, A
or N) are sent using the same message code. It is mandatory that one device
sends out only one SPA-bus message at a time to one node and waits for the
reply before sending the next message.
• If the SPA messages to be sent are longer that what is allowed by the LON
telegram length, then fragmentation/defragmentation is done as described in
[SPCP]. Each fragment as specified in [SPCP] is sent as a transparent SPA
message over LON.
PRG 3DJH
65 / 216 6SHF&/$
)LOH7UDQVIHU
File transfer is supported by transfer of the respective ASDU. The mechanism are
described in Appendix 6.
7UDQVSDUHQW'DWD7UDQVIHU
Transparent data transfer is supported by transfer of the respective ASDU.
Client Server
Control direction
Transparent Data Transparent Data (COT= 6)
Monitor direction
timeout
TD response TD response (COT=7,49)
...
TD (COT=3) Transparent Data spontaneous
TD spontaneous
Figure 31: Transparent Data Transfer sequence (Monitor and Control direction)
3DUDPHWHUWUDQVIHU
Parameters can be transferred :
• using transparent SPA-bus messages (see Command handling).
'LVWXUEDQFHUHFRUGHUILOHV
Disturbance recorder files can be transferred :
• using Transparent SPA-bus messages
• using LonTalk file transfer
• using File transfer descriped in Appendix 6
&RQILJXUDWLRQILOHV
Configuration files can be transferred :
• using LonTalk file transfer

PRG 3DJH
66 / 216 6SHF&/$
• using File transfer described in Appendix 6
7UDQVIHURI&RXQWHU9DOXHV
The features of counter value transfer are:
• The server sending requested counter values with ASDU140 must use the
originator from the counter command
• The server must indicate, if counter values are intermediate reading (IR) or
end of period reading (EOP) by the Counter Qualifier (CQS).
PRG 3DJH
67 / 216 6SHF&/$
/6*FRPPXQLFDWLRQ
3URFHVVGDWDWUDQVIHU
Process data (excluding control commands) is transferred using QHWZRUNYDULDEOHV

or /6*HYHQWV
1HWZRUNYDULDEOHV
All the service types (acked, unack_repeated, unacked) may be used for network
variables, the service type is decided during the system engineering phase.
Network variables may be used in communication in horizontal (with protection

and control devices) or vertical direction (with monitoring devices).
The following network variable types are used in LSG communication:

SNVT_state, NV_control, NV_bit_write (BWR), NV_32b_analog,
NV_16b_analog, NV_clock_warning, NV_clock. These network variable types
can be bound as indicated in the following figure. Note that in LON/SPA-
gateway NV_type and NV_bit_write are used only as types of input network
variables. LON/SPA-gateway has no input network variables of type
NV_32b_analog.
SNVT_state SNVT_state
SNVT_state NV_control
SNVT_state NV_bit_write
NV_32b_analog NV_32b_analog
NV_16b_analog NV_16b_analog
NV_clock_warning NV_clock_warning
NV_clock NV_clock
Figure 32. Possible bindings between LSG network variable types.
From the network management tool’s point of view SNVT_state, NV_control and
NV_bit_write are all of type SNVT_state. It is the responsibility of the
application software, who owns the network variables of type SNVT_state to take
care that it generates correct 16-bit bit map to enable connection to network
variables of type NV_control and NV_bit_write (on the other hand this would be
the case also when of binding two network variables of type SNVT_state).
PRG 3DJH
68 / 216 6SHF&/$
/6*HYHQWV
LSG Events are sent to the bus using acknowledged service. Each LSG Event is
sent to each monitoring device (master device) as a separate message.
If the sending of a message does not succeed (the receiving node does not send an
acknowledgement within specified time) during the first try the normal repetitions
after time-out on the link layer are done. If the event delivery fails also after
repetitions, then the same event is resent from the application layer after about 2
seconds. After a successful delivery of an event the next pending LSG event is
sent after a delay of 100...200 milliseconds. This sending algorithm is followed
for each monitoring device, so the event producer multiple pointers in a single
event buffer.
If the monitoring node runs out of communication buffers, the LSG event flow
stops automatically because the sending nodes do not receive acknowledgements.
The LSG event flow restarts when the monitoring node has communication
buffers available, because a retry is done after every 2 seconds.
&RQWUROFRPPDQGV
Control commands are sent using network variables (type SNVT_state,

NV_control or NV_bit_write).
Control network variables are sent using acknowledged service type.
Control commands may also be sent as transparent SPA-bus messages.
Parameter data is transferred using transparent SPA-bus messages. (See Figure

9.)
The transparent SPA-bus message is an explicit LON message, which contains an

ASCII character message following the coding rules of the SPA-bus protocol.
The message is sent using explicit messages with message code 41H and using
acknowledged transport service.
Both the SPA-bus command messages (R or W) and the reply messages (D, A or
N) are sent using the same message code. It is recommended that one device
sends out only one message at a time and waits for the reply before sending the
next message.
&RQILJXUDWLRQGDWDWUDQVIHU
Configuration data for LON/SPA-gateway configuration is transferred using LSG

configuration messages. These messages are sent using explicit messages with
message code 43H and using acknowledged transport service. (See Figure 9.)
PRG 3DJH
69 / 216 6SHF&/$
/6*WLPHV\QFKURQLVDWLRQ
For general information about the time synchronisation see chapter 4.6.4.
Time synchronisation principle of the LON/SPA-gateway is the following. When

a node receives NV_clock message from the network it compares the given time
to the internal time of the node. When synchronising the internal clock of the
node the following algorithm is followed:
- If the clock synchronisation message is the first one received after device start-
up then the clock of the node is set to the time given in the message.
- If the time difference is bigger than T and it has been so during the last N clock
synchronisation cycles, then the clock of the node is set to the time given in the
message.
- If the time difference is smaller than T but bigger than t, then the NV_clock
message is ignored.
- If the time difference is smaller than t, and it has been so during the last n clock
synchronisation cycles, then the clock of the node is set to the time given in the
message.
Comparison to T is used to guarantee that the clock is synchronised in case the

clock has drifted away from the master clock e.g. because of long communication
break. Comparison to t is used to guarantee that delayed clock messages are
ignored. The exact values of T and t depend on the required synchronising
accuracy. (T and t can be e.g. T >= 10 milliseconds and t <= 1 millisecond.)
PRG 3DJH
70 / 216 6SHF&/$
,QWHURSHUDEOHFRPPXQLFDWLRQ
Devices which have to communicate with interoperable LonWorks Network

devices (as defined by “LonMark Application Layer Interoperability Guidelines”)
must be able to transfer most important process data using SNVTs. Additionally
interoperable devices are be modelled using objects. Parameters are be
transferred using network variables or configuration parameter files. General
configuration data is transferred using configuration files and LonTalk file
transfer.
Complete description of how the device communicates using interoperable

communication, must be documented. The documentation is done in normal
product documentation and in node’s self-identification and self-documentation
information (SI/SD information) and optionally in node’s external interface file
(*.XIF file). The degree in which a protection or control device can utilise
interoperable communication depends on the device type. In minimum case only
a very limited amount of data is available as SNVTs and the rest of the data can
be accessed only using other type of communications (vertical, horizontal or LSG
communication).
2EMHFWPRGHO
Interoperable device are modelled using LonMark objects: node object, sensor
objects, actuator objects and controller objects. The following figures include
general object model for a substation automation node and an object model for
simple bay control unit.
The object model is “visible” in the SI/SD information of the device. The SI/SD
information defines the allocation of network variables to different objects (see
also chapter 4.6.1.3).
PRG 3DJH
71 / 216 6SHF&/$
SNVT_obj_status
SNVT_obj_request Node
Object
SNVT_alarm
LonTalk file transfer
Sensor
Sensor
Object
Sensor
Object
SNVT_xxx Interoperable
(Type #1) SNVT_xxx
Object
(Type #1)
SNVT_xxx communication
Actuator
SNVT_xxx Actuator
Object
SNVT_xxx Actuator
Object
(Type #3)
SNVT_xxx (Type #3)
Object
Controller
SNVT_xxx Controller SNVT_xxx
Object SNVT_xxx
SNVT_xxx Controller
Object
(Type #5)
SNVT_xxx (Type #5)
Object SNVT_xxx
Events
Configuration files (LonTalk file transfer)
Transparent SPA-bus messages

Non-interoperable
SNVT_state SNVT_state
SNVT_state
communication:
SNVT_state
vertical communication
Input nv horizontal communication
Input nv Output nv
Output nv LSG communication
LSG Events
LSG configuration messages
Figure 33. General features of an object model of a Substation Automation node.
PRG 3DJH
72 / 216 6SHF&/$
nvoStatus
nviRequest
Node SNVT_obj_status
SNVT_obj_request
Object nvoAlarm
SNVT_alarm
LonTalk file transfer
Sensor Object nvoBreakerStatus

Read Status of Breaker SNVT_state
Interoperable
interface
Sensor Object nvoObjectStatus1
Read Status of Object1 SNVT_state
Sensor Object
nvoObjectStatus2
Status of Object 2
SNVT_state
Sensor Object nvoLineCurrent

nviDeadBand Line Current SNVT_amp_f
SNVT_amp_f
nviBreakerControl
SNVT_state Actuator Object
Control the Breaker
Explicit messages Explicit messages

Non-interoperable
Non-standard NVs Non-standards NVs
interface
Figure 34. An example of an object model for a simple interoperable bay control
unit.
3URFHVVGDWDWUDQVIHU
Process data, like status and measurement values and control commands, are
transferred using QHWZRUNYDULDEOHV. All the service types (ackd,
unackd_repeated, unackd) may be used. The service type is decided during the
system engineering phase.
Network variable of type SNVT_alarm may be used to report time tagged alarms
to (one) monitoring device. Network variable of type SNVT_obj_status is used to
report the status bits of the objects.
(See “LonMark Application Layer Interoperability Guidelines” for more details.)
Parameter data, like relay setting values and dead-bands for measurement values,
are transferred either using QHWZRUNYDULDEOHV or FRQILJXUDWLRQSDUDPHWHUILOHV
Only relatively small amount of parameters can be transferred using network

variables. For devices with large amount of configuration information a more
compact way for configuring a node is via use of configuration parameters, which
are downloaded using the LonTalk file transfer protocol. Configuration
parameters can be either user defined or one of the standard configuration
parameter types (SCPTs). SCPTs provide standard definitions for commonly
used configuration parameters such as hysteresis, thresholds, message heartbeat
rates etc.
PRG 3DJH
73 / 216 6SHF&/$
When configuration parameters are transferred using file transfer then two types
of files are used:
- Configuration Parameter Template File and
- Configuration Parameter Data File.
The template file is an ASCII file containing following type of lines:

<hdr>,<select>,<STD>,<config index>,<dimensions><cr>
where
<hdr> = configuration record’s application
0 = entire node
1 = objects
2 = network variables
<select> = specification of the range of objects or NVs
nnn = single object or NV
nnn...nnn = range of objects or NVs
nnn.nnn.nnn = list of objects or Nvs
<STD> = use of SCPTs (Standard Configuration Parameter Types)
0 = configuration parameter is a SCPT
> 0 = length of a user defined configuration parameter in bytes
<config. index> = index of a SCPT
<dimensions> = dimensions of a SCPT
null = SCPT is not an array
not null = SCPT is a translation table
The data file is a binary file containing the configuration parameters.
Example:
Configuration parameter files to transfer 3 parameters for 2 objects. Parameters

are used defined parameters with length of 4 bytes. SCPT index is used to
identify the number/type of the user defined parameter.
Template file:
1,1,4,0,
1,1,4,1,
1,1,4,2,
1,2,4,0,
1,2,4,1,
1,2,4,2,
Data file:
100128903000499957770000
Note: As defined in other chapters of this document parameters from protection

and control devices are usually transferred using transparent SPA-bus messages.
To what degree the parameters are also available using network variables or
configuration parameter files depends on the device type.
PRG 3DJH
74 / 216 6SHF&/$
&RQILJXUDWLRQILOHV
Configuration files are sent using LonTalk file transfer protocol, as defined in
chapter 4.3.8 and in [FTLW].
PRG 3DJH
75 / 216 6SHF&/$
6\VWHPFRRUGLQDWLRQ
1HWZRUN0DQDJHPHQW
1HWZRUN0DQDJHPHQWUHVSRQVLELOLW\
The LON-bus network management is done by a Network Manager node. The

Network Manager node can be a separate PC (with a Network Management Tool
program) or it can be e.g. SCS computer. If Network Manager is a separate PC it
may be connected to the system when network management is done and then
disconnected during the normal operation of the system.
LON-bus nodes are built so that the network management can be done using
commercially available Network Management programs. But if these programs
are used then there are some limitations: only 15 entries of the address table can
be used; configuration of the device specific features by special methods (like
LSG configuration commands) is not possible.
Note: From the network management point of view the network variables used in
horizontal communication, LSG communication and interoperable
communication are treated in equal way.
7KHWDVNRIWKH1HWZRUN0DQDJHPHQW
The following things should be done by the Network Manager node:

- installing of LON-bus nodes (setting the subnet/node numbers)
- setting the network speed and other timing parameters
- installation and configuration of Routers
- binding of Network Variables (selecting service type, setting selectors, etc...)
- setting up addressing information for LSG event messages
- configuration of the cross references between the Network Variables and the
data base of the device (if they can be configured by an external tool)
LON-bus network management and configuration is done using the LonTalk

protocol’s Network Management and Diagnostic messages (with extensions for
handling the extended address table of the host nodes).
To make the management process more convenient to the user, additional

information is read from:
- SI/SD information of the device
- LSG configuration table (of LON/SPA-gateways)
- device specific configuration tables
To what extent a tool supports other than SI/SD information depends on the type
of the tool.
The detailed specification of the Network Management messages can be found for
example in the following papers: [LTPT] and [MOTD].
The basic information for the network manager is stored in the LON nodes of the
network. The following tables and arrays of the network nodes are used:
- Neuron chip domain table
- Neuron chip configuration and diagnostic data
- Network Variable configuration table (in Neuron chip or host processor)
- Extended Network Variable configuration table in the host processor memory
- Address Table in the Neuron chip
- (Extended) Address Table in the host processor
PRG 3DJH
76 / 216 6SHF&/$
- The Self Identification/Self Documentation information (SI/SD information)

- Cross references between the Network Variable Configuration table and the data
base of the device. (Protocol Dependent Object Dictionary, POD).
- LON/SPA-gateway configuration tables (configuration of the LON/SPA-
gateway data base and unit list)
Note: The network management tools can be used also to make network
configurations without having connection to the LON-bus. In this case the
required data is read from library files of the network management tool or from
interface libraries generated by other engineering tools.
6HOI,GHQWLILFDWLRQDQG6HOI'RFXPHQWDWLRQ,QIRUPDWLRQ
The SI/SD (Self Identification/Self Documentation) information stored as an array

in the memory of the node is used to keep information about the node and its
Network Variables.
The SI/SD information is utilised by the Network Manager as reference

information during the Network Variable binding. The names of the network
variables are taken from SI/SD information. If SI/SD information is not available
the same information is read using some device specific method or the names of
network variables are not shown.
The SI/SD information is read using “Query SNVT” network management

command from a host-based node and using memory read from a Neuron chip-
based node. The maximum length of the whole array is 65535 bytes. There is a
max. 255 byte description text for the whole node and max. 1023 description text
for each Network Variable. The following description show the content of the
text fields as defined by the LonMark interoperability guidelines. In our
application the node self documentation text contains the name of the node and
the NV self documentation text contains the name of the Network Variable.
The contents of the SI/SD information is defined in “[MOTD]. Additional

instructions of the use of the SI/SD information is given in “LonMark Network
Management Interoperability Guidelines. Echelon corporation.”
Example 1:
In general the contents of the SI/SD information structure is the following:
PRG 3DJH
77 / 216 6SHF&/$
SNVT header (header for the whole SI/SD information stucture):

Length msb Number of bytes in SI/SD information
Length lsb structure
num_net_vars lsb byte of the Number of Network Variables
version Version number of the SNVT definition
msb_num_net_vars msb byte of the number of Network Variables
mtag_count Number of bindable message tags
SNVT descriptor table (one entry for every NV in the node):

1 Descriptor bits. Bit ext_rec=extension records is set.
snvt_type_index Standard Network Variable type (e.g. SNVT_state = 83)
....
....
....
Self-documentation of the node (null terminated text string, max. 255 bytes):
@ ASCII “@”, separator character
x,x,x,x,...,x List of standard object types in the node.
. ASCII “.”, period character, separator.
Node name Name of the node.
Node self documentation text.
00H Null, terminator character
Self-documentation extensions records for network variables

(mask byte and text with max. 1023 bytes per Network Variable):
1 Bit mask, defining the fields to follow. Bit sd=self doc. is set.
@ ASCII “@”, separator character
object number Number of the object where the NV belongs to
| ASCII “|”, separator character
NV number Number of the NV within the object
. ASCII “.”, period character, separator.
Network Variable name Name of the Network Variable.
NV self documenation text.
00H Null, terminator character
....
....
....
Self-idenfication data for binding and status information:

alias_count
host_alias msb Number of alias network variables
host_alias lsb used by the host node.
PRG 3DJH
78 / 216 6SHF&/$
Example 2:
A node which contains 3 digital data values to be sent to the network as

network variables might contain the following SI/SD information.
Self documentation text of the node:

@0,1,1,1.Simple test node (Node contains a node object and 3
sensor objects.
Node name is “Simple test node”).
Self documentation text of the network variables:

@1|1.Digital data 1 (Object 1, first nv, nv name “Digital data 1”)
Note: Standard object types specified in self-documentaion of the node

are the following:
0 = node object
1 = open loop sensor object (sensor data sent to the network)
2 = closed loop sensor object
3 = open loop actuator object (actuator data received from the network)
4 = closed loop actuator object
5 = controller object
An example of the use of SI/SD information by the Network Manager Tool when
binding network variables is given in the following figure. The SI/SD
information is read from the nodes and NV names given in the information is
used when selecting objects to be bound. (If NV names would not be available
the selection of the objects to be bound would have to be done using NV
indexes.)
PRG 3DJH
79 / 216 6SHF&/$
Network Object bind window:

manager Node: Node: NV binding procedure:
node/tool Node 4/1 Node 5/1 - Select Node 4/1
Objects: Objects: - Select Node 5/1
0 Signal A 0 State 1 - Select Output X
2XSXW; 1 State 2 - Select Input Y
2 ,QSXW< - Connect
LON - Tool updates the config. tables
1RGH 1RGH
Network Variable
Network Variable
NV index Configuration table NV index Configuration table
0 pri|dir|VHOHFWRU|t|serv|a|DGGUBLQGH[ 0 pri|dir|VHOHFWRU|t|serv|a|DGGUBLQGH[
1 pri|dir| |t|serv|a|
1 pri|dir|VHOHFWRU|t|serv|a|DGGUBLQGH[
2 pri|dir|VHOHFWRU|t|serv|a|DGGUBLQGH[ 2 pri|dir||t|serv|a|DGGUBLQGH[
NV index 6,6'LQIRUPDWLRQ NV index 6,6'LQIRUPDWLRQ

Network Variable name: Network Variable name:
0 Signal A
0 State 1
1 2XWSXW; State 2
1
2 2 ,QSXW<
Addr. index Addr. index

Address table Address table
0 W\SH|d|QRGH|rpt|retry|rcvt|txt|VXEQHW 0 W\SH|d|QRGH|rpt|retry|rcvt|txt|VXEQHW
1 W\SH|d|QRGH|rpt|retry|rcvt|txt|VXEQHW 1 W\SH|d|QRGH|rpt|retry|rcvt|txt|VXEQHW
2 W\SH|d| _rpt|retry|rcvt|txt| 2 W\SH|d|QRGH_rpt|retry|rcvt|txt|VXEQHW
Figure 35. An example of the use of SI/SD information to help the binding of
network variables.
,QLWLDOLVDWLRQDQGVWDUWXS
*HQHUDO
Data initialisation after start-up in the monitoring devices is done in one of the
following ways:
- by initialisation of the event session (ref. chapter 4.3.2)
- by polling network variables
- by cyclic background sending of network variables
&\FOLFEDFNJURXQGVHQGLQJRIQHWZRUNYDULDEOHV
Analogue values which are sent as network variables are also sent with a slow
cyclic background sending.
The background cycle is defined by the sending device and it may be between
10...60 seconds. There may be a configuration parameter by which the cycle is
set (per data point or per device) during the system configuration or during
normal operation.
PRG 3DJH
80 / 216 6SHF&/$
&\FOLFQHWZRUNYDULDEOHSROOLQJ
A monitoring device may cyclically poll Network Variables. This has to be done
for those network variables which are not sent with cyclic background sending:
network variables carrying digital input data or network variables carrying
analogue data (from devices which do not support cyclic background sending).
1HWZRUNVXSHUYLVLRQ
1RGHVXSHUYLVLRQ
Nodes supporting event session are supervised as described in chapter 4.3.1. This
supervision is based on the idea that if the event session is working then also the
node is working. Event session is working, if the node either sends events or
acknowledgement messages, which are used for event session supervision.
Those nodes, which do not support event session and which are not able to send a
heartbeat messages (LSG, Routers or nodes which are not built for substation
automation applications) can be supervised by sequentially polling the status of
the Neuron chip. (LonTalk Network Management Message “Query Status”,
message code 51H.)
The monitoring nodes of the system should also be able to monitor the status of
interoperable LON nodes. This can be done by enabling the reception of various
types of heartbeat Network Variables (e.g. nvoStatus network variable of type
SNVT_obj_status).
6WDWXVDQGHUURUPHVVDJHV
4.6.3.2.1 Start up procedure
We differ two types of starts for a unit:
- Coldstart, is when a unit is started by turning the power on after being without
power long enough for the unit to recognise as a power off state.
- Warmstart, is when a unit restarts without any deliberate power off operation as
far as the unit can recognise and differ this operation from a temporary power
loss.
The unit sends at least a Coldstart event on power up and optional a Warmstart
event if it can restart during power on. Both events are of the ON characteristic. It
is up to the unit designer to define what state changes are defined as Coldstart and
Warmstart. Both above events have their own object addresses but do not have an
associated state and are not possible to read during a GI.
4.6.3.2.2 Status and error conditions
A unit connected to the LON bus must support at least an error status and may
support also a warning status (and more user defined status).
- Warning message (optional)
- Error message (mandatory)
PRG 3DJH
81 / 216 6SHF&/$
Both events have the ON/OFF characteristics. The interpretation of the events and
the combination of them are: the warning is representing a state where some
malfunction is detected but the main functionality of the unit is not affected. The
error is representing a state where the main function of the unit is affected.
The definition of what is main function and the judgement if it is affected in

certain operational and error states is up to the designer of the unit.
After a coldstart or a restart the two above states are assumed to be both OFF i.e.
no warning and no error state.
Both states above have their own object addresses and associated states that must
be possible to read during a GI.
4.6.3.2.3 Event buffer overflow
An event buffer overflow must be signalled with a buffer overflow event. This
event has only ON characteristic and is sent as soon as a unit recognises that
stored events, not yet read by an event receiver, have been overwritten or deleted.
The overflow event must be sent individually to each event receiver when this
happens. since it may not concern all event receivers. The buffer overflow event
has its own object address but has no associated state and is not possible to read
during a GI.
PRG 3DJH
82 / 216 6SHF&/$
7LPHV\QFKURQL]DWLRQ
Time synchronization of the LON bus devices via the bus can be done using
different methods depending on the accuracy and which method is supported by
the devices in the system .
All methods are based on network variables.
The time synchronising methods are :
• SNVT_time_stamp
• NV_clock_warning - NV_clock sequence
• Very Accurate Time Synchronisation (VATS)
In principle all synchronization methods, also in combination, can be used at the

same time but it is recommended to use only one method in a system.
1RWH Additional information is supported in [LCMF] and [TSYPY] .
6\QFKURQL]DWLRQXVLQJ6197BWLPHBVWDPS
Network variable of type SNVT_time_stamp is broadcasted to the network by a

clock master node. The node owning this type of network variable, which is
bound to the broadcasted network variable, receive the time in network variable
and synchronize their internal real-time clocks accordingly.
SNVT_time_stamp contains year, month, day, hour, minute and second. It may be
expected that in the best case the real-time clocks of the clock master node and
the other nodes are synchronized to each other with the accuracy of 10...100 ms,
if the clock master node attempts to send the SNVT_time_stamp exactly when
the full second is elapsing.
6\QFKURQL]DWLRQXVLQJ19BFORFNBZDUQLQJDQG19BFORFN
Network variables NV_clock_warning and NV_clock messages are broadcasted

to the LON Network by a clock master node once a second one after another, with
delay of 30...100 milliseconds.
When a node receives the NV_clock_warning it must stop sending other than
high priority messages and start waiting for NV_clock. The time received in
NV_clock is used to adjust the real-time clock of the node.
The length of time interval between NV_clock_warning and NV_clock message

is user configurable and it is given in network variable nv_warn_interval.
PRG 3DJH
83 / 216 6SHF&/$
9HU\DFFXUDWHWLPHV\QFKURQLVDWLRQ9$76
The VATS is a time synchronisation system for very accurate time

synchronisation. For further technical information see [LCMF] & [TSYPY] &
[LHWG].
PRG 3DJH
84 / 216 6SHF&/$
'HWDLOGHVFULSWLRQRIWLPHV\QFKURQL]DWLRQPHWKRGV
4.6.4.4.1 NV Warning Principle
The network variables for time synchronsiation are NV_clock_warning,

NV_clock and NV_time.
Network variables NV_clock_warning and NV_clock are broadcasted to the LON

bus once per second one after another, with a delay of 30...100 milliseconds.
NV_time is broadcasted to the LON bus once per minute.
When a node receives the NV_clock_warning it must stop sending other than
high priority messages and start waiting for NV_clock. When NV_clock arrives
the real-time clock of the node can be adjusted according to the time given in
NV_clock.
If a node has an external clock reference it can ignore the contents of the
NV_clock and instead receive NV_time and use it as a time reference to set the
real-time clock’s year, day, hour and minute.
The NV_time contains the time in CP562a format according to IEC870-5. This
time format includes a valid/invalid bit and a daylight-saving time bit. The same
time format is used in the event messages. The daylight-saving time bit shall
follow the NV_time.
The stopping of sending while waiting for NV_clock is done to guarantee that the
input message buffers of the nodes are empty at the time of NV_clock reception.
When the buffers are empty and nothing is sent to the bus the propagation time of
the NV_clock is more predictable than otherwise and it can be partially
compensated.
4.6.4.4.2 Requirements on the different devices.
All devices connected to LON must be able to stop sending not prioritised
messages when a NV_clock_warning is received and start again after the
NV_clock is received or after a time-out.
The devices, only synchronised via the LON bus, must be able to compensate for
propagation delays in e.g. routers.
PRG 3DJH
85 / 216 6SHF&/$
4.6.4.4.3 LON-bus clock master
On the LON-bus there must be only one clock master, which is synchronising the
other nodes to its own time. The clock master is synchronised e.g. via a minute
pulse input, satellite/radio clock or from the NCC.
In addition (or instead of ) to sending the clock messages to the network the clock
master can generate a minute pulse output for synchronisation of the LON-bus
nodes via hardwired connection.
The clock master can be one of the following:

- one of the monitoring nodes
- one of the non-monitoring nodes
- a special clock node of the system
4.6.4.4.4 Monitoring node as clock master
If a monitoring device is able to act as the clock master node, it must be possible
to enable or disable this feature. If the clock master feature of a monitoring node
is disabled, then it must receive the clock synchronising message sent by an active
clock master node.
4.6.4.4.5 Multiple subnets
If the system is divided into subnets using routers each subnet (may probably)
have to be synchronised separately. This means that a clock master node have to
have an access to all the subnets or there must be a subnet clock master in each
subnet. The subnet clock masters must be synchronised to each other e.g. using a
minute pulse.
It must be possible to configure the clock master node so that it sends the clock
synchronising messages either with subnet broadcast or domain broadcast.
Subnet broadcast is used when there are subnets separated with routers and there
is a clock master for each subnet. Domain broadcast is used if the system is
divided into subnets but routers are not used.
4.6.4.4.6 Propagation time compensation
It must be possible to configure the used propagation time compensation of the

clock master node (at least according to the used speed of the LON-bus). The
propagation time is by default tuned so that it includes the transmit propagation
time of the clock master node interface, propagation time on the LON-bus and the
receive propagation time of a MIP/P50 based node interface.
A node which has an other type of interface than the one based on the use of
MIP/P50, may further compensate the received time in the NV_clock message if
it knows how much its own receive propagation time differs from the MIP/P50
propagation time.
PRG 3DJH
86 / 216 6SHF&/$
4.6.4.4.7 Remotely located nodes
In some cases remotely located node(s) may be connected to the system via e.g. a
long twisted pair line with routers in both ends and the node(s) can only be
synchronised via the LON-bus. In this case the node’s own clock sync
compensation must include both the router delays and the delay of possibly low
speed twisted pair line. If this compensation is not possible then accurate clock
synchronisation is not possible and we must state what is the time difference
between the “main” system and the “remotely located” node(s).
PRG 3DJH
87 / 216 6SHF&/$
'DWDIRUPDWV
*HQHUDO
/216SHFLILF'DWDIRUPDWV
There are two main types of application message data formats in LON protocol:
- data format for network variables and
- data format for explicit messages
1HWZRUNYDULDEOHGDWDIRUPDW
7 6 5 4 3 2 1 0
1 d NV selector msb
NV selector lsb
NV application data
The meaning of the “d” (direction) bit is the following:

0 = the message is addressed to an input network variable
(message is a network variable update message or response message to a poll)
1= the message is addressed to an output network variable
(message is a network variable poll message)
In network variable poll message there is no NV application data.
([SOLFLWPHVVDJHGDWDIRUPDW
0 Message code
Message application data
Message code is used to classify different types of messages. The message code
can be used to differentiate the following messag data formats.
$SSOLFDWLRQGDWDPHVVDJHV
0 0 Application code LON Talk application data

„Echelon“ application data Response to Network -management / -
diagnostic commands
1HWZRUNPDQDJHPHQWFRPPDQGV
0 1 1 Network Management code Network Management commands

Network Management data
PRG 3DJH
88 / 216 6SHF&/$
1HWZRUNGLDJQRVWLFFRPPDQGV
0 1 0 1 Network Diagnostic Code Network Diagnostic commands

Network Diagnostic data
)RUHLJQIUDPHPHVVDJHV
0 1 0 0 Foreign Frame Code Foreign Frames (FOFR)

Foreign application data Transparent data transmission
1RWH
A summary of the general format of LON messages can be found in Appendix 2.
Complete decription of the protocol can be found in [LPS]
The foreign frame formats in Substation Automation applications are used in the
following way:
0HVVDJH )2)5 'HVFULSWLRQ

&RGH &RGH
40H 00 LSG event messages

41H 01 Transparent SPA messages
42H 02 Not used
43H 03 LSG configuration messages
44H 04 Events to monitoring devices
Commands, File Transfer
PRG 3DJH
89 / 216 6SHF&/$
'DWDIRUPDWVIRUKRUL]RQWDOFRPPXQLFDWLRQ
Horizontal communication is implemented using network variables.
In principle any type of network variable type can be used in horizontal

communication as far as the communication software and applications in the
communicating devices are prepared for this.
The format definitions of the network variables can be found in chapters 5.6.1 and
5.5.
Network variable polling is used to request a network variables using
request/response service.
'DWDIRUPDWVIRUYHUWLFDOFRPPXQLFDWLRQ
*HQHUDO
The data formats of vertical communication are selected to support easy

implementation in SCS computer and NCC gateway and to support the used of
existing products,
which is in many ways are bound to SPA-bus protocol.
Events are sent using explicit messages, the format of events is based on
[IEC101] standards.
'DWDPHVVDJHVLQ0RQLWRULQJDQG&RQWUROGLUHFWLRQ
*HQHUDOIRUPDWGHILQLWLRQ
The data formats for data messages used in vertical communication to transfer
events and control commands are based on the conceptional definitions of
[IEC101] and partly from [IEC103].
Especially the data presentation with value, quality and time is taken from profile
[IEC101].
The addressing and organisation of the objects is extended as it is described in
[IEC3] to allow multiple ASDU in one APDU.
The ASDU presentation is modified to allow a shorter message length.
The communication is symetrical organized in both directions.

Events =monitoring direction and commands for event session setup and general
interrogation = control direction are presented in the same formats.
The ABB application bus message flow control part is also symetrical and
includes a sequence number also in control direction.
Commands in control direction are normaly acknowledged in the form that the
command is send back in a mirror form with an substituted cause of transmission.
The data format is prepared to allow more then one ASDU per message. But it
can also be used with one ASDU only. It is a question of both sides (sender and
receiver) to allow multiple ASDUs per message. The use of multiple ASDUs is to
allow to transmit values which must be handled as one information set (e.g. the
different requiered values for synchrocheck).
The message structure allows both, several values of the same data type and / or
several data types to be transmitted in one message.
PRG 3DJH
90 / 216 6SHF&/$
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 LON Message Code
Mtype Message type Application
WinId (Sink Window ID) Window Identification layer
Sequence No. (0 / 1...255) Message Seq_No. message
Credit Credit flow control
T P/N COT Cause of Transmission
Unit No. (MSB) UNIT ADDRESS
Unit No. (LSB) OF ASDU
ASDU_No.=1 Number of different ASDUs
DMCD type TYPE IDENTIFICATION
SQ=0 0 0 0 0 0 0 1 VARIABLE STRUCTURE QUALIFIER ASDU
Object No. (MSB) OBJECT ADDRESS
Object No. (LSB) OF ASDU
data Information elements
value, quality
Information Application
Time tag object Time tag of information object Service
milliseconds ... years Data
Unit
)LJXUHExample of Event Data message in monitoring direction with one ASDU = one data signal
type
PRG 3DJH
91 / 216 6SHF&/$
7 6 5 4 3 2 1 0
Mtype Message type LON bus
WinId (Sink Window ID) Window Identification message
Sequence No. (0 / 1...255) Message Seq_No. flow control
Credit Credit
Unit No. (MSB) Data unit Unit Address
Unit No. (LSB) identifier of ASDU
$6'8B1R Number of different ASDUs
DMCD type Type Identification
Object No. (MSB) Information object identifier
Object No. (LSB)
value, quality
Unit

Object No. (LSB)
value, quality
Unit

Object No. (LSB)
value, quality
Unit
)LJXUH Event Data Message in monitoring direction with three ASDU = three different data signal
types
PRG 3DJH
92 / 216 6SHF&/$
7 6 5 4 3 2 1 0
ASDU_No=1. Number of different ASDUs
Object No. (MSB) Information OBJECT ADDRESS
Object No. (LSB) object
data Information element
value, quality
Time tag Time tag of information object

milliseconds ... years

value, quality
Time tag Time tag of information object

milliseconds ... years

value, quality
Application
Time tag Time tag of information object Service
Unit
type and SQ = 0 with three information objects.
PRG 3DJH
93 / 216 6SHF&/$
7 6 5 4 3 2 1 0
value, quality
value, quality
value, quality
type and SQ = 0 with three information objects (ASDU without time tag).
PRG 3DJH
94 / 216 6SHF&/$
7 6 5 4 3 2 1 0
value, quality
value, quality
value, quality
type and SQ = 1 with three information elements (no time tag)
PRG 3DJH
95 / 216 6SHF&/$
7 6 5 4 3 2 1 0
value, quality
value, quality
value, quality
Application
Time tag Time tag of information object Service
Unit
type and SQ = 1 with three information elements (one time tag)
1RWH : If a single ASDU_Type with time tag is packed in that manner (SQ=1, SQ_Nr > 1) one time tag
is at the end of the
ASDU and valid for all information elements
PRG 3DJH
96 / 216 6SHF&/$
$%%DSSOLFDWLRQSURWRFROIORZFRQWUROE\WHV
The definition and contents of these bytes is described in chapter 5.7.2.
PRG 3DJH
97 / 216 6SHF&/$
&DXVHRIWUDQVPLVVLRQ&27
7 6 5 4 3 2 1 0
T P/N Cause COT = Cause of Transmission
&27 Value Definition

T Test
0 no test
1 test
P/N Positive/Confirmation
0 positive confirm
1 negative confirm
Cause
0..63 numbers listed in 7DEOH are used
• P/N is used for confirmation services in the Cause field of Cause of Transmission.
In the case of irrelevance the P/N bit is zero (e.g Events).
• The Test bit defines ASDUs which were generated during test conditions.
It is used e.g. to test transmission and equipment without controlling the process.
• Confirmed application services in control direction (e.g commands) are mirrored in monitor direction with
different causes of transmission.
7DEOH: Semantics of COT which are used within this LON application guideline
0 invalid
1 periodic, cyclic
2 history event
3 spontaneous
5 request or requested
6 activation
7 activation confirmation
8 deactivation
9 deactivation confirmation
10 activation termination
11 return information caused by a remote command

12 return information caused by a local command
13 file transfer
20 interrogated by general interrogation

21 command acknowledgement positive
22 command acknowledgement negative
37 requested by general counter request

38 requested by group 1 counter request
42 transparent data
48 destination unit not reachable

49 destination unit application not reachable (busy)
PRG 3DJH
98 / 216 6SHF&/$
9DULDEOH6WUXFWXUH4XDOLILHU964

7 6 5 4 3 2 1 0
SQ SQ_No VSQ = Variable Structure Qualifier
964 Value Definiton
SQ Single/Sequence
0 Addressing of an individual information element in a number of
information
elements of the same type
1 Addressing of a sequence of information elements in one object
information object address = address of the first information
element in the
sequence of „n“ elements
SQ_No Sequence Number
0 Message contains no information object
1..127 number of information objects or information elements
PRG 3DJH
99 / 216 6SHF&/$
$GGUHVVLQJ
The adressing with the different information types are done as followed :
• Commands contain the destination address of the unit.
• Events contain source address from the unit.
5.4.2.5.1 Unit No.
7 6 5 4 3 2 1 0
Unit No. (MSB) Unit Address
Unit No. (LSB)
8QLWB1R Value Definition

0 not allowed
1..65535
The unit number is a logical node number. One physical LON node can contain
several logical nodes (e.g. the control- and protection units within a device can be
seperated in logical units connected to one physical LON node interface).
1RWH : Its not mandatory for a client to support several logical units on one
physical device
5.4.2.5.2 Object No.
The object number is the address (identification) of an information set within a

unit. An information set can be e.g. a process data value with its associated
attributes, or a unit status information (e.g. cold start) etc. The object address is
unique within one logical node.
7 6 5 4 3 2 1 0
Object No. (MSB) Object Address
Object No. (LSB)
2EMHFWB1R Value Definition

0 not relevant
1..1023 reserved for compatible use within each unit*
*They will be used for status-, error and other unit specific messages.
Within this LON application guide, only the object numbers specified in chapter:
‘5.4.2.6 Reserved object numbers’ are allowed to be used.
The others are reserved.
PRG 3DJH
100 / 216 6SHF&/$
5.4.2.5.3 SPA bay control units, protection relays
The bay control units and the protection relays are structured in the addressing to
the SPA address presentation with SPA slave, channel and data item. And also the
external presentation of an object is given in the form of SPA identification.
SPA allows the following address ranges:

1. SPA slave number = 0...999 ( 0...3E7H = max. 10 bit)
2. SPA channel number = 0...999 (0...3E7H = max. 10 bit)
3. SPA data item = 1...999999 (1...F423F H = max. 20 bit)
The bay control units can either be connected to a SPA bus master or to the LON
bus.
An object must be identified in both cases in a unique way.
That means the bay unit is responsible to support a cross reference table which
gives the SPA and LON address for the object.
SPA address when connected to Object address for LON bus Object description
SPA master connection
Slave Channel Data item Unit Object address Object name
x y z a b object number 1
x y z+1 a b+1 object number 2
5HVHUYHGREMHFWQXPEHUV
The detailed description of each defined reserved object is given in chapter

4.6.3.2
Object no. Definition

1 unit cold start
2 unit warm start
3 unit error warning
4 unit error
5 unit event buffer overflow
PRG 3DJH
101 / 216 6SHF&/$
$6'8B1R
7 6 5 4 3 2 1 0
0..255 ASDU_No
The ASDU_No. describe how many different ASDUs are included in this message.
$6'8B1R Value Definition

0 Value of 0 is not allowed
1...31 Number of different ASDUs within the message
32..255 not supported
PRG 3DJH
102 / 216 6SHF&/$
'0&'W\SHV'DWDW\SHVLQ0RQLWRULQJDQG&RPPDQG'LUHFWLRQ
'0&'7\SH,GHQWLILFDWLRQ
7 6 5 4 3 2 1 0
0..255 Type Identification
7<3(,'(17,),&$7,21 Value Definition

0 not defined
1..255
DMCD Kind of Length Informatio Direction

service in Byte1 n Type
Type
0 not used
45 Single Command CON 12 Process Control
46 Double Command CON 12 Process Control
47 Regulating Step Command CON 12 Process Control
48 Set Point Command Signed Integer 32 bit CON 16 Process Control
50 Set Point Command Short Floating Point Number CON 16 Process Control
51 Command for Bitstring 32 Bit CON 16 Process Control
101 Counter Interrogation Command CON 13 System Control
110 General Object Handling Command CON 23 System Control
120 File Ready FLT 17
122 Call Directory, Select File, Call File FLT 13
123 Last Segment FLT 14
124 Ack File FLT 13
125 Segment FLT 44
126 Directory FLT 44
129 SI (Single indication) 9
130 SI (Single indication) with time tag 16
131 DI (Double indication)2 9
132 DI (Double indication) with time tag2 16
133 Bitstring of 32 bits 13
134 Bitstring of 32 bits with time tag 20
135 Measured value signed integer 16 bit 12
136 Measured value signed integer 16 bit with time tag 19
137 Measured value real 32 bit (IEEE STD 754) 14
138 Measured value real 32 bit (IEEE STD 754) with time tag 21
139 PCV with time tag 20
140 Integrated Totals with time tag 23 Process Monitoring
141 Step Position Information 10 Process Monitoring
142 Step Position Information with Time Tag CP56 (SOE) 17 Process Monitoring
143 DI (Double indication) 9
144 DI (Double indication) with time tag 16
147 Measured value, signed integer 32 bit without Time Tag Mon 14 Monitoring
148 Measured value, signed integer 32 bit with Time Tag Mon 21 Monitoring
154 Event of Protection Equipment with time tag Mon 18 Montioring
PRG 3DJH
103 / 216 6SHF&/$
155 Packed Start Event of protection equipment with time tag Mon 19 Monitoring
156 Packed Output Circuit Information of prtection equipment Mon 19 Monitoring
201 Diagnosis Information with Time Tag CP56 & QDS 20 System Monitoring
228 General Interrogation CON 6 Inform. Control
229 Event Setup Command CON 16 Control
230 Setup Session Command CON 9 Control
231 Transparent Data 44 Dialog
7DEOHOverview of ASDU sorted for DMCD Type

1RWH The DMCD Types 131,132 should only be used for comaptibility reasons, instead use 143,144
Commands marked with CON are confirmed services and mirrored with different COT
DMCD Types marked with FLT are used for Filetransfer
1
The length of an ASDU is calculated starting with COT
2
used only for compatibility reasons
PRG 3DJH
104 / 216 6SHF&/$
,QIRUPDWLRQHOHPHQWV
5.4.4.1.1 ACR = Application Command Response
7 6 5 4 3 2 1 0
0..255 ACR = Application Command Response
$&5 Value Definition

0..255
1RWH: ACR is used for transfer of application-specific responses to a command (used for FBP response, in
general).
5.4.4.1.2 AFQ = Acknowledge File Qualifier
7 6 5 4 3 2 1 0
ER PN AFQ = Acknowledge File Qualifier
$)4 Value Definition

ER
0 default
1 request memory space not available
2 checksum failed
3 unexpected communication service
4 unexpected name of file
PN
0 not relevant
1 postive acknowledge of file transfer
2 negative acknowledge of file transfer
5.4.4.1.3 ASC = ASCII Character
7 6 5 4 3 2 1 0
0..255 ASC = ASCII Character
$6& Value Definition

0..255 ASCII 8 bit code
5.4.4.1.4 AVA = Attribute Value
7 6 5 4 3 2 1 0
Octet 1
.
. AVA = Attribute Value
.
.
Octet 26
$9$ Value Definition

generic up to 26 Octet
1RWH : Length of AVA depends on length of attribute value (LOV) and is specified by the TOV.
PRG 3DJH
105 / 216 6SHF&/$
5.4.4.1.5 BCR = Binary counter reading
7 6 5 4 3 2 1 0
S Value (MSB)
Value BCR = Binary counter reading
Value
Value (LSB)
%&5 Value Definition

Value -231...+231-1 Counter readings unidirectional or bidirectional values
Sign 0 positive
1 negative
1RWH : Binary counter values are accumulated pulses over a dedicated time.
5.4.4.1.6 BSI = Binary State Information
7 6 5 4 3 2 1 0
32 MSB 25
24 17 BSI = Binary State Information

16 9
8 LSB 1
%6, Value Definition

0 or 1 Bit string pattern
5.4.4.1.7 CHS = Checksum
7 6 5 4 3 2 1 0
0..255 CHS = Checksum
&+6 Value Definition

0..255 arithmetic sum disregarding overflows (sum modulo 256) over all
octets of a complete file.
PRG 3DJH
106 / 216 6SHF&/$
5.4.4.1.8 CPT = Time tag information
7 6 5 4 3 2 1 0
Milliseconds (MSB)
Milliseconds (LSB)
IV Res1 Minutes CPT
SU Res2 Hours
Day of week Day of month
Res3 Months
Res4 Years
Milliseconds 0..59999
Minutes 0..59
Res1 0
IV Time Valid/Invalid
0 valid
1 invalid (no sync trigger for the respective device)
Hours 0..23
Res2 0
SU Summer time
0 standard local time
1 daylight saving time
Day of month 1..31
Day of week 1..7
Months 1..12
Res3 0
Years 0..99
Res4 0
5.4.4.1.9 CP16 = Two Octet Binary Time
7 6 5 4 3 2 1 0
Milliseconds (MSB) CP16 = Two Octet Binary Time
Milliseconds (LSB)
Milliseconds 0..59999
1RWH: It is used for an elapsed time such as „Relay operating time“ or „Relay duration time“.
PRG 3DJH
107 / 216 6SHF&/$
5.4.4.1.10 CQS = Counter Qualifier with Sequence
7 6 5 4 3 2 1 0
IR DRS Res SQ CQS = Counter Qualifier & Sequence

IR Intermediate Reading of counters
0 no Intermediate Reading of counter values (EPR)
1 Intermediate Reading of counter values (IR)
DRS Device restarted
0 device not restarted
1 device restarted
RES 0 Reserved
SQ 0..31 Sequence Number
5.4.4.1.11 DCO = Double Command
7 6 5 4 3 2 1 0
QOC DCS DCO = Double Command
'&2 Value Definition

QOC Qualifier of Command
DCS Double Command State
0 invalid
1 OFF
2 ON
3 invalid
Direct commands are transferred with S/E set to zero (S/E = 0, Execute).
5.4.4.1.12 DPI = Double Point Information
7 6 5 4 3 2 1 0
DPI DPI = Double Point Information
'3, Value Definition
0 indeterminate or intermediate state

1 OFF
2 ON
3 indeterminate state
PRG 3DJH
108 / 216 6SHF&/$
5.4.4.1.13 DPI_rev= Double Point Information reversed
7 6 5 4 3 2 1 0
DPI_rev DPI_rev = Double Point Information reversed
'3,BUHY Value Definition

1 ON
2 OFF
1RWH : The definition of DPI_rev is used only for compatibility reason and should QRW EH XVHG
in future implementation.
5.4.4.1.14 DIQ = Double-Point Information with Quality Descriptor
7 6 5 4 3 2 1 0
IV NT SB BL 0 0 DPI DIQ = Double Point Information
',4 Value Definition
IV
0 valid
1 invalid
NT
0 topical
1 not topical
SB
0 not substituted
1 substituted
BL
0 not blocked
1 blocked
RES 0 Reserved
DPI
1 determined state OFF
2 determined state ON
Definition of Quality Descriptor (BL, SB, NT, IV) see 5.4.4.1.35
PRG 3DJH
109 / 216 6SHF&/$
5.4.4.1.15 DIQ_rev = Double-Point Information with Quality Descriptor reversed
7 6 5 4 3 2 1 0
IV NT SB BL 0 0 DPI_rev DIQ_rev = Double Point Information reversed
',4BUHY Value Definition
IV
0 valid
1 invalid
NT
0 topical
1 not topical
SB
0 not substituted
1 substituted
BL
0 not blocked
1 blocked
RES 0 Reserved
DPI_rev
1 determined state ON
2 determined state OFF
Definition of Quality Descriptor (BL, SB, NT, IV) see 5.4.4.1.35
5.4.4.1.16 EQL1 = Error Qualifier Level 1
7 6 5 4 3 2 1 0
0..255 EQL1 = Error Qualifier Level 1
(4/ Value Definiton

0..255 Each value define the representation of lower Error Qualifier
Levels
7 6 5 4 3 2 1 0
(4/ Value Definiton

0..255 depending on upper Error Qualifier Levels
7 6 5 4 3 2 1 0
(4/ Value Definiton

PRG 3DJH
110 / 216 6SHF&/$
0 1 2 3 4 5 6 7
UI8 EQL4 = Error Qualifier Level 4
(4/ Value Definiton

5.4.4.1.20 ESQ = Event Setup Qualifier
7 6 5 4 3 2 1 0
HI FI_No. ESQ = Event setup qualifier
(64 Value Definition

FI_No Event filter mask set
0 Default event filter mask set
1..127 Filter mask set number which will be used for event transmission
filtering
HI Event history request flag
0 no history events requested
1 Send event history queue
5.4.4.1.21 FAN = Fault Number (16 bit)
7 6 5 4 3 2 1 0
Value (MSB) FAN = Fault Number
Value (LSB)
FAN Value Definition

Value 0 ...+65535
1RWH The fault number is used to identify an event associated with a protection function, for example, a start/pick-up from a
protection equipment will increment a fault number. This means that a sequence with an unsuccessful auto-reclosure
will be recorded as two separate fault numbers. The fault number need not to be reset or preset.
5.4.4.1.22 FRQ = File Ready Qualifier
7 6 5 4 3 2 1 0
P/N Res FRQ = File Ready Qualifier
)54 Value Definition

P/N
0 positive confirm of select, request, deactivate or delete
1 negative confirm of select, request, deactivate or delete
Res reserved bits (not used)
PRG 3DJH
111 / 216 6SHF&/$
5.4.4.1.23 LSQ Last Segment Qualifier
7 6 5 4 3 2 1 0
0..255 LSQ = Last Segment Qualifier
/64 Value Definition

0 not relevant
1 file transfer without deactivation
2 file transfer with deactivation
5.4.4.1.24 LOFD = Lenght of File or Directory
7 6 5 4 3 2 1 0
MSB LOFD = Length of File od Directory
LSB
/2)' Value Definition

0..4.29E09 number of octets of the complete file (up to 4 Gbyte)
5.4.4.1.25 LOS = Lenght of Segment
7 6 5 4 3 2 1 0
0..n LOS = Length of Segment
/26 Value Defintion

0..n number of octets of the segment (1 ≤ n ≤ 31)
5.4.4.1.26 LOV = Length of Attribut Value
7 6 5 4 3 2 1 0
0..n LOV = Length of Attribut value
/29 Value Defintion

0..n number of octets of the attribut value (1 ≤ n ≤ 26)
5.4.4.1.27 LTD = Length of Transparent Data
7 6 5 4 3 2 1 0
0..255 LTD = Length of Transparent Data
/7' Value Definition

0..255
PRG 3DJH
112 / 216 6SHF&/$
5.4.4.1.28 MLQ = Measured value limit quality
7 6 5 4 3 2 1 0
GRN GRP 0 0 L4 L3 L2 L1 MLQ= Measured value quality
MLQ Value Definition

L1 0 L1 = low limit alarm= value L1
1 value L1
L2 0 L2 = low limit warning = value L2
1 value L2
L3 0 L3 = high limit warning = value L3
1 value L3
L4 0 L4 = high limit alarm = value L4
1 value L4
GRP 0 positive gradient not exceeded
1 positive gradient exceeded
GRN 0 negative gradient not exceeded
1 negative gradient exceeded
Measured value limit violation quality. The quality bits are set for each limit independent. If e.g. the value exceeds
the highest upper limit L3 and L4 are set.
L1, L2, L3, L4 = LIMIT VIOLATION / NO LIMIT VIOLATION

L1 to L4 is set when the measured value is lower (L1, L2) or higher (L3, L4) than the given limit values. If L1 to
L4 is zero the value is in the normal range.
GRP = POSITIVE GRADIENT EXCEEDED / NOT EXCEEDED
The value increased faster then the specified maximum delta within a time window. The exact definition of
gradient supervision has to be detailed by the measuring unit.
GRN = NEGATIVE GRADIENT EXCEEDED / NOT EXCEEDED
The value decreased faster then the specified maximum delta within a time window. The exact definition of
gradient supervision has to be detailed by the measuring unit.
PRG 3DJH
113 / 216 6SHF&/$
5.4.4.1.29 NOFD = Name of File or Directory
7 6 5 4 3 2 1 0
MSB NOFD = Name of File or Directory
LSB
12)' Value Definition

0 name of file or directory is not known
1..65535 name of file or directory
5.4.4.1.30 OAD = Originator Address
0 1 2 3 4 5 6 7
OAD__Originator Originator_Address
OAD_Internal_Adress
2$' Value Definition

OAD__Originator
0 originator not valid
1..255 system specific
OAD_Internal_Address
0 internal address not valid
1..255 system specific
5.4.4.1.31 OCI = Output circuit information of protection equipment
7 6 5 4 3 2 1 0
GC CL1 CL2 CL3 Res Res Res Res OCI = Output circuit information of P.E
2&, Value Definition

GC 0 no general command to output circuit
1 general command to output circuit
CL1 0 no command to output circuit phase L1

1 command to output circuit phase L1


Res reserved bits (not used)
PRG 3DJH
114 / 216 6SHF&/$
5.4.4.1.32 PCQ = Pulse counter qualifier
7 6 5 4 3 2 1 0
IV NT SB BL Res Res CA CY PCQ = Pulse counter quality
3&4 Value Definition

CY 0 no counter overflow occured in the corrresponding integration
period
1 counter overflow occured in the corrresponding integration
period
(wrap around)
CA 0 counter was not adjusted since the last reading
1 counter was adjusted since the last reading (e.g. reset to zero)
BL to IV see QDS description (5.4.4.1.35)
The pulse counter quality bits are extended to the use within substation control.
5.4.4.1.33 QCC = Qualifier of Counter Interrogation Command
7 6 5 4 3 2 1 0
FRZ RQT QCC = Qualifier of Counter Interrogation Command
4&& Value Definition

FRZ Freeze
0 no freeze or reset
1 counter freeze without reset
2 counter freeze with reset
3 counter reset
RQT Request
0 no counter requested
1 request counter group 1
5 general request counter
6..31 reserved for standard definitions
32..63 reserved for special use (private range)
PRG 3DJH
115 / 216 6SHF&/$
5.4.4.1.34 QDP = Quality Descriptor for events of Protection Equipment
7 6 5 4 3 2 1 0
IV NT SB BL EI Res Res Res QDP = Quality Descriptor for events of P.E
4'3 Value Definition

IV
0 valid
1 invalid
NT
0 topical
1 not topical
SB
0 not substituted
1 substituted
BL
0 not blocked
1 blocked
EI 0 elapsed time valid
1 elapsed time invalid
RES 0 Reserved
Definition of Quality Descriptor (BL, SB, NT, IV) see 5.4.4.1.35.
EI = Elapsed time valid / invalid
Elapsed time is valid if it was correctly acquired. If the acquisition function recognizes abnormal conditions the
elapsed time is marked invalid. The elapsed time of the Information object is not defined under this condition. The
mark INVALID is used to indicate to the destination that the elased time may be incorrect and cannot be used.
PRG 3DJH
116 / 216 6SHF&/$
5.4.4.1.35 QDS = Quality Descriptor, Separate Octet
7 6 5 4 3 2 1 0
IV NT SB BL Res Res Res OV QDS = Quality Descriptor
4'6 Value Definition

IV
0 valid
1 invalid
NT
0 topical
1 not topical
SB
0 not substituted
1 substituted
BL
0 not blocked
1 blocked
RES 0 Reserved
OV
0 no overflow
1 overflow
IV = INVALID/VALID
A value is valid if it is correctly acquired. After abnormal conditions of the information source are recognised
(missing or non operating updating devices, oscillating source) the value is then marked invalid. The value of the
information object is not Defined under this condition (e.g. hardware failure of the board). The mark INVALID is
used to indicate to the destination that the value may be incorrect and cannot be used.
NT = NOT TOPICAL/TOPICAL
A value is topical if the most recent update was successful. It is not topical if it was not updated successfully
during a specified time interval or it is unavailable.
SB = SUBSTITUTED/NOT SUBSTITUTED
The value of the information object is provided by input of an operator (dispatcher) or by an automatic source.
BL = BLOCKED/NOT BLOCKED
The value of the information object is blocked for transmission; the value remains in the state that was acquired
before it was blocked. Blocking and deblocking may be initiated by a master unit (on operators request) or
automatically when an internal state cause it (e.g. when oscillation suppression occurs for an indication)
OV = NO OVERFLOW/OVERFLOW
The value of the information object is beyond a preDefined range of value (mainly applicable to analog values).
PRG 3DJH
117 / 216 6SHF&/$
5.4.4.1.36 QOC = Qualifier of Command
7 6 5 4 3 2 1 0
S/E QU QOC = Qualifier of Command
42& Value Definition
S/E Select/Execute
0 Execute
1 Select
QU
0..31 compatible or private definitions
The qualifier of command PXVW be accessable on the application layer for private definition reason.
e.g. projects specific definition.
Compatible or private definition of QOC must be transferred over LON
5.4.4.1.37 QOI = Qualifier of Interrogation
7 6 5 4 3 2 1 0
0..255 QOI = Qualifier of Interrogation
42, Value Description

0 not used
1..19 reserved for standard definitions
20 (Sub-)Station Interrogation (global)
37..255 reserved for special use (private range)
5.4.4.1.38 QST = Queue State
7 6 5 4 3 2 1 0
0..255 QST = Queue State
467 Value Definition

0 Overflow
1 No overflow
2..255 invalid
5.4.4.1.39 QUT = Queue Type
7 6 5 4 3 2 1 0
0..255 QUT = Queue Type
487 Value Definition

0 Event Queue (SOE)
1 State Change Queue
2 Command Queue
3 Counter Value Queue
4 Transparent Data Queue
5 Diagnosis Information Queue
6..255 reserved for additional definitions
PRG 3DJH
118 / 216 6SHF&/$
5.4.4.1.40 RCO = Regulating Step Command
7 6 5 4 3 2 1 0
QOC RCS RCO = Regulating Step Command

QOC Qualifier of Command (see 5.4.4.1.36)
RCS Regulating Step Command State
0 invalid
1 next step LOWER
2 next step HIGHER
3 invalid
PRG 3DJH
119 / 216 6SHF&/$
5.4.4.1.41 SCQ = Select and Call Qualifier
7 6 5 4 3 2 1 0
ERN SF SCQ = Select and Call Qualifier

ERN
0 default
1 request memory space not available
2 checksum failed
3 unexpected communication service
4 unexpected name of file
SF
0 not used
1 select file
3 deactivate file
4 delete file
8 list file or directory
5.4.4.1.42 SCO = Single Command
7 6 5 4 3 2 1 0
QOC Res SCS SCO = Single Command

QOC Qualifier of Command (see 5.4.4.1.36)
RES Reserve
SCS Single Command State
0 OFF
1 ON
PRG 3DJH
120 / 216 6SHF&/$
5.4.4.1.43 SEP = Single-Event of protection equipment
7 6 5 4 3 2 1 0
IV NT SB BL EI Res ES SEP = Single Event of Protection Equipment
6(3 Value Definition
IV Valid/Invalid
0 valid
1 invalid
NT Topical/Not Topical
0 topical
1 not topical
SB Substitutef/Not Substituted
0 not substituted
1 substituted
BL Blocked/Not Blocked
0 not blocked
1 blocked
EI Elapsed time
0 elapsed time valid
1 elapsed time invalid
RES 0 Reserved
ES Event State
1 OFF
2 ON
PRG 3DJH
121 / 216 6SHF&/$
5.4.4.1.44 SIQ = Single-Point Information with Quality Descriptor
7 6 5 4 3 2 1 0
IV NT SB BL Res Res Res SPI SIQ = Single point information with quality descriptor
6,4 Value Definition
IV Valid/Invalid
0 valid
1 invalid
NT Topical/Not Topical
0 topical
1 not topical
SB Substitutef/Not Substituted
0 not substituted
1 substituted
BL Blocked/Not Blocked
0 not blocked
1 blocked
RES 0 Reserved
SPI Single Point Indication
0 OFF
1 ON
5.4.4.1.45 SOFD = Status of File or Directory
7 6 5 4 3 2 1 0
FA FOR NOM NFD Res SOFD = Status of File
62)' Value Definition

FA
0 file waits for transfer
1 transfer of this file is active
FOR
0 Name defines file
1 Name defines directory
NOM
0 there is another entry of the directory following
1 last entry of directory
NFD
0 File or directory present
1 No file or directory present
RES
0 not used
PRG 3DJH
122 / 216 6SHF&/$
5.4.4.1.46 SPE = Start events of protection equipment
7 6 5 4 3 2 1 0
GS SL1 SL2 SL3 SIE SRD Res SPE = Start Event of Protection Equipment
63( Value Definition

GS
0 no general start of operation
1 general start of operation
SL1
0 no start of operation phase L1
1 start of operation phase L1
SL2
SL3
SIE
0 no start of operation IE (earth current)
1 start of operation IE (earth current)
SRD
0 no start of operation in reverse direction
1 start of operation in reverse direction
RES
0 not used
Start events are generated by the protection equipment when it detects faults. Start events are transient
information.
Commands to output circuits are generated by the protection equipment when it decides to trip the circuit breaker.
Output circuit information is transient information.
The time between start and end of operation is the relay duration time. The time between start of operation and
command to output circuit is the relay operating time.
PRG 3DJH
123 / 216 6SHF&/$
5.4.4.1.47 SPI = Single-Point Information
7 6 5 4 3 2 1 0
SPI SPI = Single Point Information
63, Value Definition

0 OFF
1 ON
5.4.4.1.48 SSQ = Setup Session Qualifier
7 6 5 4 3 2 1 0
0..255 SSQ = Session Setup Qualifier
664 Value Definiton

0 Download of substituted informations
1..255 reserved
5.4.4.1.49 SVAF = Short floating point number (Scaled value floating)
R32-IEEE STD 754 floating point number. The resolution is not defined. If the resolution is coarser than the unit
of the LSB, then the least significant bits are set to zero.
7 6 5 4 3 2 1 0
S Value (Exponent)
Exp Value (Fraction) (MSB) SVAF = Short floating point number
Value (Fraction)
Value (Fraction) (LSB)
SVAF Value Definition
Value -2128+2104...+2128-2104 IEC 870-5-4 type 5: REAL (R), IEEE STD 754
S sign (+/-) Sign bit
0 positive
1 negative
This subclause is in line with IEEE Standard 754 and specifies the following ranges for floating point arithmetics:
Range : -2128+2104...+2128-2104, that is : -3,4x1038...+3,4x1038

Smallest negative number : -2-149, that is : -1,4x10-45
Smallest positive number :+2-149, that is : +1,4x10-45
PRG 3DJH
124 / 216 6SHF&/$
5.4.4.1.50 TCI = Time Counter Interrogation
7 6 5 4 3 2 1 0
Sec Res Res TCI = Timer Counter Interrogation
7&, Value Definition

Sec 0..59 Seconds
Res 0 Reserved
1RWH Used for determine the saving point for counter values in counter interrogation command
5.4.4.1.51 TOH = Type of Handling
7 6 5 4 3 2 1 0
0..255 TOH = Type of Handling
72+ Value Description

0 substitute
1 desubstitute
2 block
3 deblock
4 substitute & block
5 desubstitute & deblock
6 set (parameter)
7..255 reserved for future use
5.4.4.1.52 TOV = Type of Object Value
7 6 5 4 3 2 1 0
0..255 TOV = Type of Object Value
729 Value Description

0 value not present
1 SPI
2 DPI
3 SVAF
4 BSI
5 BCR
6 VAI
7 VAI32
8 VTI
9 CP16
10 CPT
1RWH : IF TOV = 0 then LOV = 0
5.4.4.1.53 VAI = Signed integer information (16 bit)
7 6 5 4 3 2 1 0
Value (MSB) VAI = Signed integer value
Value (LSB)
VAI Value Definition

Value - 32768 ...+32767 Two’s bit complement presentation
The resolution is not defined. Transmitter and receiver have to be configured in the same way to engineer the
represented value. The format is represented in Two’s bit complement form. This is a general format for a value
which is represented by a 16 bit word including sign.
PRG 3DJH
125 / 216 6SHF&/$
5.4.4.1.54 VAI32 = Signed integer information (32 bit)
7 6 5 4 3 2 1 0
Value (MSB) VAI = Signed integer value 32 bit
Value (LSB)
VAI Value Definition

Value - 231 ...+231-1 Two’s bit complement presentation
The resolution is not defined. Transmitter and receiver have to be configured in the same way to engineer the
represented value. The format is represented in Two’s bit complement form. This is a general format for a value
which is represented by a 32 bit word including sign.
5.4.4.1.55 VTI = Value with Transient State Indication
7 6 5 4 3 2 1 0
Tran Value VTI = Value with Transient State Indication
97, Value Definition

Tran Transient
0 equipment is not in transient state
1 equipment is in transient state
Value -64..+63
PRG 3DJH
126 / 216 6SHF&/$
'HILQLWLRQDQG3UHVHQWDWLRQRI$6'8
V'0&'W\SHV
5.4.4.2.1 Commands
5.4.4.2.1.1 DMCD type = 45 = C_SC_N , Single Command
Single Information Object

7 6 5 4 3 2 1 0
Defined in 5.4.2.3 CAUSE OF TRANSMISSION
Defined in 5.4.2.5.1 UNIT ADDRESS
OF ASDU
Defined in 5.4.2.7 ASDU_Number
0 0 1 0 1 1 0 1 TYPE IDENTIFICATION
SQ 0 0 0 0 0 0 1 VARIABLE STRUCTURE QUALIFIER
Defined in 5.4.2.5.2 OBJECT ADDRESS
OF ASDU
Defined in 5.4.4.1.30 OAD = ORIGINATOR ADDRESS
Defined in 5.4.4.1.42 SCO

Defined in 5.4.4.1.1 ACR
CAUSE OF TRANSMISSION:
In control direction:
6 activation
8 deactivation
In monitor direction:
49 destination unit application not reachable
1RWH The QU of QOC is defined for this command as :

48 Value Definition
0 no additional information
1 short pulse duration (circuit breaker), duration determined by
a parameter in the control device
2 long pulse duration, duration determined by a parameter in
the control device
3 persistent output
PRG 3DJH
127 / 216 6SHF&/$
5.4.4.2.1.2 DMCD type = 46 = C_DC_N , Double Command

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.11 DCO

6 activation
8 deactivation
1RWH The QU of QOC is defined for this command as :

48 Value Definition
0 no additional information
1 short pulse duration (circuit breaker), duration determined by
a parameter in the control device
2 long pulse duration, duration determined by a parameter in
the control device
3 persistent output
PRG 3DJH
128 / 216 6SHF&/$
5.4.4.2.1.3 DMCD type = 47 = C_RC_N , Regulating Step Command

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.40 RCO

6 activation
8 deactivation
PRG 3DJH
129 / 216 6SHF&/$
5.4.4.2.1.4 DMCD type = 48 = C_SE_NA , Set-Point Command, Signed Integer 32 bit:

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.54 VAI32 = Signed Integer value 32 bit
Defined in 5.4.4.1.36 QOC=Qualifier of command

6 activation
8 deactivation
1RWH Bit 0,1 of the QOC are set to 0.
PRG 3DJH
130 / 216 6SHF&/$
5.4.4.2.1.5 DMCD type = 50 = C_SE_NC , Set-Point Command, Short Floating Point Number:

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.49 SVAF = Short Floating Point number

6 activation
8 deactivation
PRG 3DJH
131 / 216 6SHF&/$
5.4.4.2.1.6 DMCD type = 51 = C_BO_NA , Bitstring Command, 32 Bit:

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.6 BSI=Binary State Information, 32 bit

6 activation
8 deactivation
PRG 3DJH
132 / 216 6SHF&/$
5.4.4.2.1.7 DMCD type = 101 = C_CI_N , Counter Interrogation Command

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.36 QCC=Qualifier of Counter Command

Defined in 5.4.4.1.50 TCI
6 activation
PRG 3DJH
133 / 216 6SHF&/$
5.4.4.2.1.8 DMCD type = 110 = C_GO_N , General Object Handling Command

7 6 5 4 3 2 1 0
OF ASDU (Destination Unit)
0 0 0 0 0 0 0 1 VARIABLE STRUCTURE QUALIFIER
OF ASDU
Defined in 5.4.2.5.1 Unit Address of

handled object
Defined in 5.4.2.5.2 Object Address of
handled object
Defined in 5.4.4.1.51 TOH = Type of handling
Defined in 5.4.4.1.52 TOV = Type of value
Defined in 5.4.4.1.26 LOV = Length of Attribut value
Defined in 5.4.4.1.4 AVA = Attribute value
6 activation
48 destination not reachable
49 destination application not reachable
1RWH Unit address of ASDU specifies destination unit of general object handling command.
1RWH Object address of ASDU is set to 0.
1RWH Unit Address and Object Address specify the object to be handled , it is used for all types of handling.
1RWH Any modification of object attributes causes the update of the object to higher levels via event channel. In
case of substitution this means that the new value is transferred with the corresponding qualifier SB=1 (SB is
set in the bay unit).
PRG 3DJH
134 / 216 6SHF&/$
5.4.4.2.1.9 DMCD type = 228 = C_IC_NA, GI command/response

7 6 5 4 3 2 1 0
T P/N Defined in 5.4.2.3 CAUSE OF TRANSMISSION
OF ASDU
1 1 1 0 0 1 0 0 TYPE_IDENTIFICATION
CAUSE OF TRANSMISSION
In control direction :
6 activation of a GI
8 deactivation of a GI
In monitoring direction :
7 activation confirmation of a GI
9 deactivation confirmation of a GI
GI command send from event client to event server and forces the event server to transmit all process information
with their actual values.
The command is confirmed in the way that it is mirrored in monitor direction with different cause of
transmissions.
GI response is transmitted from event server to event client to acknowledge the GI command or to indicate end of
GI message transmission.
PRG 3DJH
135 / 216 6SHF&/$
5.4.4.2.1.10 DMCD type = 229 = C_ES_NA, ES command/response

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
HI FI_No. ESQ = Defined in 5.4.4.1.20
Time tag of information object

CPT
CPT = Defined in 5.4.4.1.8
In control direction
6 activation of event transmission
8 deactivation of event transmission
In monitoring direction
21 + P/N=0 command acknowledgement positive
22 or 21 + P/N=1 command acknowledgement negative
ES command (Event Setup) is sent from event client to event server to establish or to reestablish the transmission
of events from event server to event client.
transmissions.
ES response is transmitted from event server to event client to acknowledge the ES command.
1RWH The time represents the start point from which on the event client wants to get the history events
transmitted
if the history bit is set. History events transmitted may be all events or from the time being present in
CPT.
PRG 3DJH
136 / 216 6SHF&/$
5.4.4.2.1.11 DMCD type = 230 = C_SS_NA, Setup Session command/response

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Defined in 5.4.4.1.48 SSQ = Setup Session Qualifier
6 activation of transmission of setup information
8 deactivation of transmission of setup information
In monitoring direction
7 activation confirmation of transmission of setup information
9 deactivation confirmation of transmission of setup information
Setup Session command (SS) is sent from client to server to establish or to reestablish the transmission of setup
session data (e.g. substituted informations) from client to server.
transmissions.
SS response is transmitted from server to client to acknowledge the SS command.
PRG 3DJH
137 / 216 6SHF&/$
5.4.4.2.2 Events
5.4.4.2.2.1 DMCD type =129 = M_SP_N, Single-point information without Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
IV NT SB BL 0 0 0 SPI SIQ = Defined in 5.4.4.1.44
20 Interrogated by general interrogation
PRG 3DJH
138 / 216 6SHF&/$
5.4.4.2.2.2 DMCD type =130 = M_SP_T, Single-point information with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
IV NT SB BL 0 0 0 SPI SIQ = Defined in 5.4.4.1.44

CPT
2 history event
3 spontaneous
PRG 3DJH
139 / 216 6SHF&/$
5.4.4.2.2.3 DMCD type =131 = M_DP_NR, Double-point information without Time Tag (reversed)

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
IV NT SB BL 0 0 DPI_rev DIQ_rev = Defined in 5.4.4.1.15
1RWH: The reversed DPI is only used for compatible reasons. !!
5.4.4.2.2.4 DMCD type =132 = M_DP_TR, Double-point information with Time Tag (reversed)

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
IV NT SB BL 0 0 DPI_rev DIQ_rev = Defined in 5.4.4.1.15

CPT
2 history event
3 spontaneous
1RWH: The reversed DPI is only used for compatible reasons. !!
PRG 3DJH
140 / 216 6SHF&/$
5.4.4.2.2.5 DMCD type =133 = M_BO_N, Bitstring of 32 bit without Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Bitstring (MSB) BSI = Defined in 5.4.4.1.6
Bitstring
Bitstring
Bitstring (LSB)
IV NT SB BL 0 0 0 OV QDS = Defined in 5.4.4.1.35
1RWH: The OV bit is not used and set to 0.

If a 16 bit value is transferred the LSB is used.
PRG 3DJH
141 / 216 6SHF&/$
5.4.4.2.2.6 DMCD type =134 = M_BO_T, Bitstring of 32 bit with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Bitstring (MSB) BSI = Defined in 5.4.4.1.6
Bitstring
Bitstring
Bitstring (LSB)

CPT
2 history event
3 spontaneous
1RWH: The OV bit is not used and set to 0.

If a 16 bit value is transferred the LSB is used.
PRG 3DJH
142 / 216 6SHF&/$
5.4.4.2.2.7 DMCD type =135 = M_MEN_N, Measured value, signed integer without Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Value (MSB) VAI = Defined in 5.4.4.1.53
Value (LSB)
GRN GRP 0 0 L4 L3 L2 L1 MLQ= Defined in 5.4.4.1.28
1 periodic/cyclic
PRG 3DJH
143 / 216 6SHF&/$
5.4.4.2.2.8 DMCD type =136 = M_MEN_T, Measured value, signed integer with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Value (MSB) VAI = Defined in 5.4.4.1.53
Value (LSB)

CPT
1 periodic/cyclic
2 history event
3 spontaneous
5 requested
PRG 3DJH
144 / 216 6SHF&/$
5.4.4.2.2.9 DMCD type =137 = M_MEF_N, Measured value, short floating point without Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Value
Value SVAF = Defined in 5.4.4.1.49
Value
Value (LSB)
1 periodic/cyclic
PRG 3DJH
145 / 216 6SHF&/$
5.4.4.2.2.10 DMCD type =138 = M_MEF_T, Measured value, short floating point with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Value
Value SVAF = Defined in 5.4.4.1.49
Value
Value (LSB)

CPT
1 periodic/cyclic
2 history event
3 spontaneous
5 requested
PRG 3DJH
146 / 216 6SHF&/$
5.4.4.2.2.11 DMCD type =139 = M_PC_T, Pulse counter value with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
S Value
Value BCR = Defined in 5.4.4.1.5
Value
Value (LSB)
IV NT SB BL 0 0 CA CY PCQ = Defined in 5.4.4.1.32

CPT
1 periodic, cyclic
1RWH For transfer of counter value only Type 139 RU Type 140 can be used
PRG 3DJH
147 / 216 6SHF&/$
5.4.4.2.2.12 DMCD type = 140 = M_IT_T, Integrated Totals with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
Defined in 5.4.2.5 OBJECT ADDRESS
OF ASDU
Defined in 5.4.4.1.5 BCR = Binary Counter Reading
Defined in 5.4.4.1.32 PCQ = Pulse Counter Qualifier

Defined in 5.4.4.1.10 CQS = Counter Qualifier with Seq.
Defined in 5.4.4.1.8 CPT
1 periodic,cyclic
37 requested by general counter request
38 requested by group1 counter request
1RWH For transfer of counter value only Type 139 RU Type 140 can be used
PRG 3DJH
148 / 216 6SHF&/$
5.4.4.2.2.13 DMCD type = 141 = M_ST_N, Step Position Information

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.55 VTI=Value with Trans. State Indication
Defined in 5.4.4.1.35 QDS=Quality Descriptor
20 general interrogation
PRG 3DJH
149 / 216 6SHF&/$
5.4.4.2.2.14 DMCD type = 142 = M_ST_T, Step Position Information with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.50 VTI=Value with Trans. State Indication
2 history event
3 spontaneous
PRG 3DJH
150 / 216 6SHF&/$
5.4.4.2.2.15 DMCD type =143 = M_DP_N, Double-point information without Time Tag

7 6 5 4 3 2 1 0
OF ASDU
SQ VARIABLE STRUCTURE QUALIFIER
. OF ASDU
IV NT SB BL 0 0 DPI DIQ = Defined in 5.4.4.1.14
5.4.4.2.2.16 DMCD type =144 = M_DP_T, Double-point information with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
IV NT SB BL 0 0 DPI DIQ = Defined in 5.4.4.1.14

CPT
2 history event
3 spontaneous
PRG 3DJH
151 / 216 6SHF&/$
5.4.4.2.2.17 DMCD type =147 = M_MEI_N, Measured value, signed integer 32 bit without Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Defined in 5.4.4.1.54 VAI32 = Signed integer value 32 bit

1 periodic/cyclic
PRG 3DJH
152 / 216 6SHF&/$
5.4.4.2.2.18 DMCD type =148 = M_MEI_T, Measured value, signed integer 32 bit with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
. OF ASDU
Defined in 5.4.4.1.54 VAI32 = Signed integer value 32 bit


CPT
1 periodic/cyclic
2 history event
3 spontaneous
5 requested
PRG 3DJH
153 / 216 6SHF&/$
5.4.4.2.2.19 DMCD type = 154 = M_EP_TA , Event of protection equipment with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.43 SEP = Single Event of Protection Epuipment
Defined in 5.4.4.1.21 FAN = Fault Number
Defined in 5.4.4.1.9 CP16 = Two Octet Binary Time

CPT
3 spontaneous
PRG 3DJH
154 / 216 6SHF&/$
5.4.4.2.2.20 DMCD type = 155 = M_EP_TB , Packed Start Event of protection equipment with Time
Tag

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.46 SPE = Start Event of Protection Equipment
Defined in 5.4.4.1.34 QDP = Quality descriptor of P.E

CPT
3 spontaneous
PRG 3DJH
155 / 216 6SHF&/$
5.4.4.2.2.21 DMCD type = 156 = M_EP_TC , Packed Output circuit information of protection
equipment with Time Tag

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.31 OCI = Output circuit information of P.E.
Defined in 5.4.4.1.34 QDP = Quality descriptor of P.E

CPT
3 spontaneous
PRG 3DJH
156 / 216 6SHF&/$
5.4.4.2.3 File Transfer
5.4.4.2.3.1 DMCD type = 120 = F_FR_N , File Ready
Single Information Object (SQ=0)

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.29 NOFD = Name of File or Directory
Defined in 5.4.4.1.24 LOFD = Length of File or Directory
Defined in 5.4.4.1.22 FRQ = File Ready qualifier
13 file transfer
5.4.4.2.3.2 DMCD type = 122 = F_SC_N , Call Directory, Select File, Call file

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.41 SCQ = Select and call qualifier
5 request (only for Call Directory)

13 file transfer (all except for Call Directory)
PRG 3DJH
157 / 216 6SHF&/$
5.4.4.2.3.3 DMCD type = 123 = F_LS_N , Last Segment

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.29 NOFD = Name of File od Directory
Defined in 5.4.4.1.23 LSQ = Last Segment qualifier

Defined in 5.4.4.1.7 CHS = Checksum
13 file transfer
5.4.4.2.3.4 DMCD type = 124 = F_AF_N, Ack File

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.2 AFQ = Ack file Qualifier
13 file transfer
PRG 3DJH
158 / 216 6SHF&/$
5.4.4.2.3.5 DMCD type = 125 = F_SG_N , Segment:

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.25 LOS = Length of segment

Octet 1
Segment
Octet 31
13 file transfer
1RWH The Type 125 is transferred with a fixed length always 31 Octets with SQ=0, ASDU_Number = 1
LOS determine how many Octets in the segment are valid
PRG 3DJH
159 / 216 6SHF&/$
5.4.4.2.3.6 DMCD type = 126 = F_DR_T , Directory

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.24 LOFD = Length of file or directory
Defined in 5.4.4.1.45 SOFD = Status of File or directory
Creation time of file or directory
ASC 1
. Name of file or directory in
Defined in 5.4.4.1.3 ASCII - Code
.
.
.
ASC 20
3 spontaneous
5 requested
PRG 3DJH
160 / 216 6SHF&/$
5.4.4.2.4 Diagnosis Information
5.4.4.2.4.1 DMCD type = 201 = M_GD_T , Generic Diagnosis Information Time Tagged with
Qualifier

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.16 Error Qualifier Level 1
3 spontaneous
5 requested
Diagnosis Information with Time Tag is issued within the devices of the substation control system, e.g., if a state
change of Status of Node has occurred.
UNIT and OBJECT ADDRESS of ASDU of diagnosis information equals the address of the issuing device or
module.
Diagnosis Information with different error qualifier must have a different object address
PRG 3DJH
161 / 216 6SHF&/$
5.4.4.2.5 Transparent Data
5.4.4.2.5.1 DMCD type = 231 = T_TD_N , Transparent Data:

7 6 5 4 3 2 1 0
OF ASDU
OF ASDU
Defined in 5.4.4.1.27 LTD = Length of Transparent Data (n)
Octet 1
Transparent Data
Octet 35
6 activation
In monitor direction
3 spontaneous
No General Interrogation for Transparent Data is applicable (can not be state information)
PRG 3DJH
162 / 216 6SHF&/$
'DWDIRUPDWVIRU/6*FRPPXQLFDWLRQ
1HWZRUNYDULDEOHV
19W\SH 6197BVWDWH
The format of SNVT_state is Defined in chapter 5.6.1.1.
PRG 3DJH
163 / 216 6SHF&/$
19W\SH 19BFRQWURO
Description:
The CONTROL NV is used to give a double command (select before execute

method) to control an object.
Coding:
1 0 selector msb
selector lsb
x x x x x x x x x = bit not used
x x x x d d d d dddd = data bits
0001 = select open (or direct open)
0010 = select close (or direct close)
0100 = execute
1000 = cancel
Note:
Only one of the data bits may be set in one message.
Note:
The same NV type can also be used to control an object which can be controlled
without preselection. In this case data bit values “direct open” or “direct close”
are used and “execute” and “select” are not used..
PRG 3DJH
164 / 216 6SHF&/$
19W\SH 19BELWBZULWH%:5
Description:
The NV_bit_write is used to control one digital output point (hardware or

software.) The bit value indicates the desired logic state of the digital output
point.
Bit write command is used to set or reset one bit in a 16-bit bit string in the
receiving device. The bit string is identified with one NV selector.
Coding:
1 0 selector msb
selector lsb
iiii xxxx iiii = bit number (0..15)
xxxx xxx d xxxx xxxx xxx = not used
d = bit value (0 or 1)
1RWH
The NV_bit_write is used in cases when e.g. mapping to ANSI X3.28 protocol’s
BitWrite command is required.
PRG 3DJH
165 / 216 6SHF&/$
19W\SH 19BEBDQDORJ
Description:
The 32-bit analog NV is an information object used to represent a hardware or

software analog point. The 32-bit signed value could represent a digitized signal
or calculted value.
The value field shows the current value of the analog input or output at the time
of reporting, or the last reported value form the originating device.
Coding:
1 0 selector msb
selector lsb
data, byte 1, msb 32-bit analog value, 32-bit signed fixed point integer value,
data, byte 2 negative values presented with two’s complement,
data, byte 3 scaling factor 1000 (E.g. value 1.05 is sent as 1050)
data, byte 4, lsb
1RWH
The 32-bit analog NV can be used to send the value of an analog input point or to
set a value for a analog output point or set point.
PRG 3DJH
166 / 216 6SHF&/$
19W\SH 19BEBDQDORJ
Description:
The 16-bit analog NV is an information object used to represent a hardware or

software analog point. The 16-bit signed value could represent a digitized signal
or calculted value.
The value field shows the current value of the analog input or output at the time
Coding:
1 0 selector msb
selector lsb
data, byte 1, msb 16-bit analog value, 16-bit signet fixed point integer value,
data, byte 2, lsb negative values presented as two’s complement,
with scaling factor 100 (E.g. value 1.05 is sent as 105)
1RWH
The 16-bit analog NV can be used to send the value of an analog input point or to
set a value for a analog output point or set point.
1RWH
Many of the Standard Network Variables (SNVT) are coded with 16 bits, but the
scaling factor may be 1, 10, 100 or 1000. It is recomended that the data collecting
devices like monitoring devices and gateways to other systems are prepared for
this.
PRG 3DJH
167 / 216 6SHF&/$
/6*(YHQW0HVVDJHV
LSG event messages are used to report SPA-event or the change of state of an
application function or digital or analog data point. Event messages use explicit
message frame format and message code is 40H.
Coding:
0 40H Message code = 40H.

1 event type (8 bits)
2 object address - event id. (type 0,7,8) or
3 (16 bits) - 00 + 14-bit NV selector (type 1,2)
4 - 32-bit integer (scale 1000) or
5 event data - 16-bit mask + 16-bit data or
6 (32 bits) - 16-bit slave/node number
7
8 year (msb)
9 year (lsb)
10 month
11 day
12 hour
13 minute
14 second
15 ms and 100 us (msb) Bytes 15 and 16: a 16 bit number including
16 ms and 100 us (lsb) milliseconds and hundreds of microseconds.
Object address coding:
Event type 0 and 7:
1 slave index (3 bits) channel number (6 bits) event number (6 bits)
Event type 8:
1 object number / channel number (9 bits) event number (6 bits)
Event type 1 and 2:
00 NV selector (14 bits)
The following LSG event types are used:
PRG 3DJH
168 / 216 6SHF&/$
Type code Event type

0 SPA event,
(e.g. event generated from SPA-bus events)
1 Analog event, event with 32 bit analog data value.
The data value is a 32-bit signed integer value scaled with 1000.
2 Digital event, event with 16 bit digital data.
Bytes 4,5 contain 16-bit mask indicating the changed bits and
bytes 6,7 contain the 16-bit data itself.
7 SPA analog event,
event generated from SPA-bus analog event.
Analog data in data part (32-bit integer scaled with 1000).
8 Extended SPA event,
Slave/node number in data part bytes 4 and 5.
PRG 3DJH
169 / 216 6SHF&/$
/6*HYHQWW\SH /6*63$HYHQW
Description:
LSG SPA event message format is used by LON/SPA-gateway to send events

received from a SPA-bus slave devices.
Coding:

1 0 Event type = 0
2 1 sss cccc sss=slave index (3 bits), cccc=channel number (6 bits)
3 cc ee eeee eee=event number (6 bits)
4
5 event data No data !
6 (32 bits)
7
8 year (msb)
9 year (lsb)
10 month
11 day
12 hour
13 minute
14 second
Note:
The receiver of the LSG SPA Event must be able to convert the 3-bit slave index
to original SPA-bus slave number. (See also LSG extended SPA event).
Note:
If the SPA-bus channel number in the SPA-device is bigger than 63 the higher
order bits will be placed in the slave index field (this is not a problems, if there is
only one SPA-slave under the LON/SPA-gateway). It is the responsibility of the
receiving device to handle this situation correctly.
PRG 3DJH
170 / 216 6SHF&/$
/6*HYHQWW\SH /6*DQDORJHYHQW
Description:
LSG analog event message format is used by to send changed values of an analog
information objects.
Coding:

1 1 Event type = 1
2 00 selector msb
3 selector lsb
4 Analog data
5 32-bit integer
6 (scale 1000)
7
8 year (msb)
9 year (lsb)
10 month
11 day
12 hour
13 minute
14 second
Note:
In order to use this message format the sending device must have a corresponding
network variable of type NV_32b_analog, which specifies the NV selector value
to be used..
PRG 3DJH
171 / 216 6SHF&/$
/6*HYHQWW\SH /6*GLJLWDOHYHQW
Description:
LSG digital event message format is used by to send changed values of a digital
information objects.
Coding:

1 2 Event type = 2
2 00 selector msb
3 selector lsb
4 Data mask 16-bit mask indicating the changed bits in
5 (16-bits) the data (1=bit changed, 0=bit not changed)
6 Digital data 16-bit data
7 (16 bits)
8 year (msb)
9 year (lsb)
10 month
11 day
12 hour
13 minute
14 second
Note:
In order to use this message format the sending device must have a corresponding
network variable of type SNVT_state, which specifies the NV selector value to
be used.
PRG 3DJH
172 / 216 6SHF&/$
/6*HYHQWW\SH /6*63$DQDORJXHHYHQW
Description:
LSG SPA analogue event message format is used by LON/SPA-gateway to send

so called “Analogue SPA-bus events” received from a SPA-bus slave devices.
Coding:

1 7 Event type = 7
2 1 sss cccc sss=slave index (3 bits), ccc=channel number (6 bits)
3 cc ee eeee eee=event number (6 bits)
4 Analog data
5 32-bit integer
6 (scale 1000)
7
8 year (msb)
9 year (lsb)
10 month
11 day
12 hour
13 minute
14 second
Note:
The receiver of the LSG SPA analogue event must be able to convert the 3-bit
slave index to original SPA-bus slave number.
Note:
If the SPA-bus channel number in the SPA-device is bigger than 63 the higher
order bits will be placed in the slave index field (this is not a problems, if there is
only one SPA-slave under the LON/SPA-gateway). It is the responsibility of the
receiving device to handle this situation correctly.
PRG 3DJH
173 / 216 6SHF&/$
/6*HYHQWW\SH /6*H[WHQGHG63$HYHQW
Description:
LSG extended SPA event message format is used by LON/SPA-gateway to send

events received from a SPA-bus slave devices.
The “slave number” is an identification of the node running the application. The
slave number for each node in the system must be unique.
Coding:

1 8 Event type = 8
2 1 ccc cccc ccc = channel number (9 bits)
3 cc ee eeee eee = event number (6 bits)
4 Slave Slave number = number of the node (16bits)
5 number
6
7
8 year (msb)
9 year (lsb)
10 month
11 day
12 hour
13 minute
14 second
Note:
This event type is planned but not yet (23.08.1995) implemented in LON/SPA-
gateway or SRIO1000M.
Note:
The benefit of LSG event type 8 compared to LSG event type 0, is that in type 8
the whole slave number is given, and the monitoring device does not have to have
a look-up table for converting slave index to slave number.
PRG 3DJH
174 / 216 6SHF&/$
/6*&RQILJXUDWLRQ0HVVDJHV
LSG configuration messages are sent using explicit message with message code
43H. These messages are used to send and read configuration data of LON/SPA-
gateways.
43H Message code 43H.
Command/response
message composed of ASCII
characters. Command/response end character, carriage return.
0DH
PRG 3DJH
175 / 216 6SHF&/$
7UDQVSDUHQW63$EXVPHVVDJHV
The Transparent SPA-bus Message is an explicit LON message, which contains

an ASCII character message following the coding rules of the SPA-bus protocol.
The message is sent using explicit messages with message code 41H and using
acknowledged transport service.
Both the SPA-bus command messages (R or W) and the reply messages (D, A or
N) are sent using the same message code. It is recommended that one device
sends out only one message at a time and waits for the reply before sending the
next message.
Transparent SPA-bus messages are used to read and write parameter data.
Parameter data may be one or more parameter values or it may be a “parameter
file”, e.g. disturbance recorder file.
Coding:

">" or "<" Message start character “>" or “<“.
SPA-bus message
":" End of data part/header.
CC Two checksum characters.
0DH Message end character, carriage return.
Note:
Long SPA-bus messages are sent in pieces of max. 45 bytes. Each separately sent
piece (except the last piece) contains end characters ’&’, 0DH, 0AH (46th, 47th
and 48th byte).
Coding of long message:
First piece:
">" or "<" Message start character ">" or “<“.
SPA-bus message bytes End of data piece.
"&" Message end characters,
0DH carriage return, line feed.
0AH
Following pieces:
SPA-bus message bytes
"&" End of data piece.
0DH Message end characters,
0AH carriage return, line feed.
Last piece:
PRG 3DJH
176 / 216 6SHF&/$

SPA-bus message bytes
0DH Message end character, carriage return
PRG 3DJH
177 / 216 6SHF&/$
63$SDUDPHWHUUHDGPHVVDJH
Description:
Parameter read is done by sending a transparent SPA message (with

acknowledged service), which contains a SPA parameter read message. The
SPA-reply is returned using a separate transparent SPA message (with
acknowledged service.)
The reply message may be sent using one or more transparent SPA messages,
each containing one piece of the SPA-reply message.
Coding:
Request message to a device:

">" Message start character.
sss SPA-bus slave number: 1...3 characters, 0...999.
“R” ASCII “R”, indicating Read operation.
SPA-bus message
Reply message from the device:

"<" Message start character.
SPA-bus reply message
PRG 3DJH
178 / 216 6SHF&/$
63$SDUDPHWHUZULWHPHVVDJH
Description:
Parameter write is done by sending a transparent SPA message (with

acknowledged service), which contains a SPA parameter write message. The
SPA-reply is returned using a separate transparent SPA message (with
acknowledged service.)
Coding:
Request message to a device:

">" Message start character.
sss SPA-bus slave number: 1...3 characters, 0...999.
“W” ASCII “W”, indicating Write operation.
SPA-bus message
Reply message from the device:

"<" Message start character.
SPA-bus reply message
PRG 3DJH
179 / 216 6SHF&/$
'DWDIRUPDWVIRULQWHURSHUDEOHFRPPXQLFDWLRQ
5HFRPPHQGHG6WDQGDUG1HWZRUN9DULDEOH7\SHV6197
19W\SH 6197BFRXQW
Description:
SNVT_count is used for the Lon clock Master for configuration reasons of time
synchronisation.
(see [LCMF]).
19W\SH 6197BOHYBGLVF
Description:
SNVT_lev_disc is used for the Lon clock Master for diagnostic reasons of time
synchronisation.
(see [LCMF]).
19W\SH 6197BVWDWH
Description:
SNVT_state can be used to communicate the state of a set of 1 to 16 Boolean

values. Each bit indicates the state of the boolean, with for example the following
interpretations:
0 1
off on
inactive active
disabled enabled
low high
false true
normal alarm
The value field shows the current value of the digital inputs or outputs at the time
Coding:
1 0 selector msb Network variable selector
selector lsb
data, byte 1 16-bit binary value
data, byte 2
SNVT_state can be used to transfer the state of 1 to 16 digital inputs or it can be

use to set the state of 1 to 16 output bits or binary set points.
Note:
(YHQWKRXJKDELWGLJLWDO19PD\FRQWDLQWKHYDOXHRIGLIIHUHQWREMHFWVLWLV
UHFRPPHQGHGWKDWRQH19LVXVHGSHURQHREMHFW
Note:
The (C-language) structure definition of SNVT_state is:
PRG 3DJH
180 / 216 6SHF&/$
typedef struct {
unsigned bit0 : 1;
unsigned bit1 : 1;
...
unsigned bit15: 1;
} SNVT_state;
19W\SHV³I´ IORDWLQJSRLQW6197V
Description:
Floating point SNVTs can be used to represent a hardware or software analogue

point. The floating point value could represent a digitised signal or calculated
value.
The value field shows the current value of the analogue input or output at the time
Coding:
1 0 selector msb
selector lsb
data, byte 1 (sign, exponent) 32-bit floating point value
data, byte 2 (exponent lsb, mantissa msb) IEEE 754 format
data, byte 3 (mantissa) 1 sign bit, 8 exponent bits, 23 mantissa bits
data, byte 4 (mantissa lsb)
The floating point SNVTs can be used to send the value of an analogue input
point or to set a value for a analogue output point or set point.
Note: Some of the floating point Standard Network Variable types useful in our
application:
Name SNVT type number Usage

SNVT_ampt_f 48 Current
SNVT_volt_f 66 Voltage
SNVT_count_f 51 Counter
SNVT_elec_whr_f 68 Watt hour
SNVT_freq_f 75 Frequency
SNVT_angle_f 49 Angle
SNVT_pwr_fact_f 99 Power factor
SNVT_res_f 60 Resistance
SNVT_temp_f 63 Temperature
PRG 3DJH
181 / 216 6SHF&/$
19W\SH 6197BDODUP
Description:
This output network variable transmit alarm data for each object on a node to a
monitoring node. This message containing all the data relating to the alarm
condition is sent whenever an alarm condition occurs or upon receiving a request
via Object Request network variable.
Coding:
1 0 selector msb
selector lsb
1 Identification string of the node.
2 Location ID Stored in node configuration data.
3 of the node
4 (6 bytes)
5
6
7 Object id Idenfication of the object within the node.
8 (16 bits)
9 Alarm type Type of alarm.
10 Priority level Alarm priority.
11 Index to SNVT SNVT id of the value.
12 (16 bits) (Data type of the value.)
13 Value, 4 bytes of fewer.
14 Value
15 (4 bytes)
16
17 Year Year 0...3000 (0 = year not specified)
18
19 Month 0...12 (0 = not specified)
20 Day 0...31 (0 = not specified)
21 Hour 0...23
22 Minute 0...59
23 Second 0...59
24 Millisecond 0...999
25
26 Alarm limit, 4 bytes of fewer.
27 Alarm limit
28 (4 bytes)
29
Alarm types:
0 = no alarm condition present
1 = unspecified alarm condition present
2 = total/service alarm 1
5 = alarm low limit alarm clear 1
6 = alarm low limit alarm clear 2
7 = alarm high limit alarm clear 1
8 = alarm high limit alarm clear 2
9 = alarm low limit alarm 1
10 = alarm low limit alarm 2
11 = alarm high limit alarm 1
12 = alarm high limit alarm 2
Priority levels:
PRG 3DJH
182 / 216 6SHF&/$
0 = priority level 0, lowest alarm priority level

1 = prority level 1,
2 = priority level 2
3 = priority level 3,
4 = priority level 4, highest alarm priority level
* The “alarm_type” field is treated as follows:
b7 b6 b0
Structure EVbit Event Code or Alarm type
Example:
Event example 1 failure_in_programming (event user’s code)

Alarm example 0 AL_HIGH_LMT_ALM_2
** The “location” field in the SNVT_alarm defines the location of the node.
The location field in an alarm or event is normally the same as the contents of the
“location” field in the Neuron chip configuration stucture (which is stored in the
Neuron chip EEPROM memory.) Neuron chips location field is used to pass a
six-byte ASCII string describing the physical location of the node to the network
management node. Normally this string is set during installation time by the
network management node.
In case of gateway nodes, which are sending alarm/event messages to the LON
network, the location field in an alarm or event messages may also be used to
indicate the physical location of the original source of the alarm/event.
It is recomeded that in this case: the 3 last ASCII characters of the “location” =
node number of the source of event in the other network. (For example: location
= xxx125, would be used to transfer events from node number 125 of the other
network.)
Note:
Connection between a certain NV and an Object can be found in the SI/SD

information of the node. From this information it can be found the connection
between a specific object identification number and corresponding network
variable index. Then the selector value of the variable used to transfer the same
information (in non-alarm situations) can be found from the Network Variable
Configuration table. The checking of this connection must be done in a
monitoring node receiving Alarm Output Nvs (if the Alarm Output Nvs are also
used to update the data base). Note that because of this, it is best to define
alarming objects so that they have only one output network variable: then there is
one to one correlation between object id number, network variable index and
network variable selector.
For more information see [LALI] and [LSNMP].
PRG 3DJH
183 / 216 6SHF&/$
19W\SH 6197BREMBVWDWXV
Description:
SNVT_obj_status reports the status for any object on a node.
This NV is transmitted whenever a request is received via Object Request NV and

when the Object Status Max. Send Timer expires. When the Object Status Max.
Send Timer expires, the status of each object (including the node object) is sent
sequentially in round-robin fashion, one object status per expiration of the timer.
Coding:
1 0 selector msb
selector lsb
1 object_id Idenfication of the object
2 (16 bits) within the node.
3 1 2 3 4 5 6 7 8
4 8 10 11 12 13 14 15 16
5 17 18 19 reserved
6 reserved
Status bits sent in the message:

Bit Bit name Meaning
1 invalid_id requested ID is not implemented in this node
2 invalid_request request for unimplemented function
3 disabled object disabled
4 out_of_limits object exceeds alarm limits
5 open_circuit open circuit detected
6 out_of_service object not functional
7 mechanical_fault mechanical fault detected
8 feedback_failure feedback signal not received
9 over_range max range exceeded
10 under_range min range exceeded
11 electrical_fault electrical fault detected
12 unable_to_measure I/O line failure
13 comm_failure network communication failure
14 fail_self_test self test failed
15 self_test_in_progress self test in progress
16 locked_out node is on-line, but actuator movement is prevented
17 manual_control actuator under local control
18 in_alarm object is in alarm
19 in_override object is overridden
PRG 3DJH
184 / 216 6SHF&/$
19W\SH 6197BREMBUHTXHVW
Description:
This input network variable provides the mechanism to request the status of an
object or a particular mode for a particular object within a node.
Coding:
1 0 selector msb
selector lsb
1 object_id Idenfication of the object
2 (16 bits) within the node.
3 object_request
Possible values for the object_request byte:
Value Name Meaning

0 rq_normal enable object, report object status
1 rq_disabled disable object, report object status
2 rq_update_status just report the object status
3 rq_self_test perform object self-test, report status
4 rq_update_alarm update alarm status, report status
5 rq_report_mask report status bit mask
6 rq_override override object, report object status
The “status bit mask” of an object specifies the supported status bits. A one bit in
the mask means that the object may set the corresponding bit in the object status.
PRG 3DJH
185 / 216 6SHF&/$
'DWDIRUPDWVIRUV\VWHPFRRUGLQDWLRQPHVVDJHV
)RUPDWRIQHWZRUNPDQDJHPHQWPHVVDJHV
LON network management and configuration is done using the LonTalk

protocol’s Network Management and Diagnostic messages.
The detailed specification of the Network Management messages can be found for
example in the following papers: [LTPT] and [MOTD]
In host based nodes the Neuron chip of the network interface processes most of
the network management and diagnostic messages with the following exceptions:
- Set Node Mode (on-line and off-line only)
- Wink
- Update Net Variable Configuration (only if “host selection” is enabled)
- Query Net Variable Configuration (only if “host selection” is enabled)
- Query SNVT
- Network Variable Fetch
The host processor is handling the network variables to enable use of more than
62 network variables, “host selection” in the MIP software is enabled. This
means that the Network Variable Configuration table is located in the host
processor’s memory. Additionally host software may keep a copy of the Address
Table and Domain Table in the memory of the host processor by cyclically
polling the contents of the Domain Table and the Address Table from the memory
of the local network interface’s Neuron chip.
The address table in the host processor memory may be extended to 255 entries.
The first 15 entries (entry numbers 0...14) are copied from the local Neuron chip’s
memory and can thus be accessed in the same way as with normal Neuron chip-
based nodes, using Network Management messages “Query Address” and
“Update Address” or “Update Group Address Data”.
The extension of the address table can only be accessed using the extended
Network Management messages:
- Update Extended Address message
- Query Extended Address message
A standard Network Variable Configuration table contains a 4-bit reference to an

address table entry. To utilise an extended Address Table, an addition to the
Network Variable Configuration table is required.
The extended Network Variable Configuration table in the host processor’s

memory can be accessed using the following extended message:
- Update Extended Net Variable Config message
- Query Extended Net Variable Config message
PRG 3DJH
186 / 216 6SHF&/$
8SGDWH([WHQGHG$GGUHVVPHVVDJH
Write to the extended address table in the memory of the host processor.
Message format:
3DH Message code
addr_index Address table entry index.
type Type of address entry or 80H + group size.
d node_or_member d = domain index, node_or_member = node number or member of a
group
rpt_timer retry
rcv_timer tx_timer
subnet_or_group subnet number or group number
This message is the same as the standard “Update Address” message except the
message code.
Address entry types:

0 = unbound address table entry (if d|node_or_member = 0)
0 = turnaround address (if byte “d|node_or_member” = 1)
1 = subnet/node address
3 = broadcast address
80H...8FH = group address, bits 0...6 specify the size of the group
Timer fields:
rpt_timer = time interval between repetitions in unack_repeated service
retry = retry count
rcv_timer = receive timer for multicast(group) messages
tx_timer = transmit timeout for acked or request/response service
Positive response message:

26H Message code
Negative response message:

06H Message code
Note:
This message is not Defined in LonTalk protocol, this is an extension created for
substation automation applications.
PRG 3DJH
187 / 216 6SHF&/$
4XHU\([WHQGHG$GGUHVVPHVVDJH
Read from the extended address table in the memory of the host processor.
Message format:
3CH Message code
addr_index Address table entry index.
This message is the same as the standard “Query Address” message, except the
message code.
Positive response message:
27H Message code

type Type of address entry or 80H + group size.
d node_or_member d = domain index, node_or_member = node number or member of a
group
rpt_timer retry
rcv_timer tx_timer
subnet_or_group subnet number or group number
Negative response message:

07H Message code
Note:
This message is not Defined in LonTalk protocol, this is an extension created for
substation automation applications.
PRG 3DJH
188 / 216 6SHF&/$
8SGDWH([WHQGHG1HW9DULDEOH&RQILJPHVVDJH
This message is used to write the extended Network Variable Configuration table
in the host processor’s memory.
Message format for write message
(special format of “Updata Net Variable Config” message):

6BH message code
255 network variable index
nv_index_high hight byte of nv index (if byte nv_index = 255)
nv_index_low low byte of nv index (if byte nv_index = 255)
p d nv_selector_high p = nv priority (1 bit), d = direction (1-bit),
nv_selector_high = nv selector 6 msb bits
nv_selector_low nv selector 8 lsb bits
t st a addr_index t = turnaround (1 bit), st = service type(2 bits),
a = authentication(1 bit),
addr_index (4 bits) = index to address table
ext_addr_index index to extended address table
Service type field st defines the service type used with the message:
0 = ackd, aknowledged
1 = unackd_repeated, unacknowledged/repeated
2 = unackd, unacknowledged
This messages is distrinquished from the standard “Update Net Variable

Configuration” message, because it contains one byte more in its data part, byte
“ext_addr_index”.
If the index to address table is 15, then

- addr_index = index to address table
- ext_addr_index = 0FFH
If the index to address table is = 15, then
- addr_index = 0FH and
- ext_addr_index = index to address table
If both addr_index = 0FH and ext_addr_index = 0FFH, then there is no

connection to the address table.
Positive response to write message:

2BH message code
Negative response to write message:

0BH message code
Note: This message is not Defined in LonTalk protocol, this is an extension. The
message codes are the same as used in “Update Net Variable Config” message,
but the contents of the request message is extended by one byte in the end of the
message.
PRG 3DJH
189 / 216 6SHF&/$
Note: In case the index to address table is 15, there should be no reason to use
the “Update Extended Net Variable Config message” but the standard “Update
Net Variable Config” messages should be used instead.
PRG 3DJH
190 / 216 6SHF&/$
4XHU\([WHQGHG1HW9DULDEOH&RQILJPHVVDJH
This message is used to read the extended Network Variable Configuration table
in the host processor’s memory.
Message format for read message
(special format of “Query Net Variable Config” message):

68H message code 68H
255 255
1 nv_index_high hight byte of nv index (msb-bit of the byte is always set)
nv_index_low low byte of nv index
Positive response to read message:

28H message code
p d nv_selector_high p = nv priority (1 bit), d = direction (1-bit),
nv_selector_high = nv selector 6 msb bits
nv_selector_low nv selector 8 lsb bits
t st a addr_index t = turnaround (1 bit), st = service type(2 bits),
a = authentication(1 bit),
addr_index (4 bits) = index to address table
ext_addr_index index to extended address table
If the index to address table is 15, then

- addr_index = index to address table
- ext_addr_index = 0FFH
If the index to address table is = 15, then
- addr_index = 0FH and
- ext_addr_index = index to address table
If both addr_index = 0FH and ext_addr_index = 0FFH, then there is no

connection to the address table.
Negative response to read message:

08H message code
Note: This message is not Defined in LonTalk protocol, this is an extension. The
message codes are the same as used in “Query Net Variable Config” message, but
the contents of the response message is extended with one byte in the end of the
message. Additionally the request message’s first data byte is always = 255 and
the msb-bit of the second data byte is always set.
PRG 3DJH
191 / 216 6SHF&/$
)RUPDWRILQLWLDOL]DWLRQDQGVWDUWXSPHVVDJHV
6HVVLRQVHWXSPHVVDJHV
The format of session and transmission protocol control messages, which are used
when sending application messages (vertical communication). Chapter 4.1.8.4
contain explanation of the fields of the session and transmission control messages.
6HVVLRQFRQWUROPHVVDJHV
5.7.2.2.1 s-conn.req, Session connection request
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
d 0 0 1 0 0 1 1 Message type (13H) LON bus
Credit Credit
1RWH : d := direction 0 = client to server
5.7.2.2.2 s-conn.reject or s-disconn.req, Session connection rejected or disconnected
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
d 1 0 1 0 0 t 1 Message type (D3H,D1H,51H,53H) LON bus
Credit Credit
1RWH : d := direction 1 = server to client, 0 = client to server, t : 0 = without ACK 1 = with Ack
5.7.2.2.3 s-conn.accept, Session connection accepted
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
d 0 1 1 0 0 1 1 Message type (B3H) LON bus
Credit Credit
1RWH : d := direction 1 = server to client
PRG 3DJH
192 / 216 6SHF&/$
7UDQVPLVVLRQFRQWUROPHVVVDJHV
5.7.2.3.1 TranNack, Transmission sequence not acknowledged
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
d 0 0 0 0 1 0 0 Message type (84H,04H) LON bus
Credit Credit
This message is used to request lost message(s) to be resent. Sequence number

indicates the sequece number of the lost message. The lost message and
unacknowledged messages sent after that will be resent.
1RWH : d := direction 1 = server to client, 0 = client to server
5.7.2.3.2 TranAck, Transmission sequence acknowledged
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
Credit Credit
This message is used to aknowledge received messages. Sequence number

indicates the sequence number of the next expected message.
5.7.2.3.3 AckReq, Acknowledgement request
7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
Credit Credit
Data as
Data Defined by one of DMCD types
in chapter 5.4.3
This fomat is used to send data, when immediate acknowledgement from the
receiver is requested.
PRG 3DJH
193 / 216 6SHF&/$
1RWH “Normal” data message has the following format:

7 6 5 4 3 2 1 0
0 1 0 0 0 1 0 0 Message code 44H
Credit Credit
Data as
Data Defined by one of DMCD types
in chapter 5.4.3
PRG 3DJH
194 / 216 6SHF&/$
*HQHUDOLQWHUURJDWLRQPHVVDJHV
Format for GI command and GI response messages is defined in chapter

5.4.4.2.1.9.
PRG 3DJH
195 / 216 6SHF&/$
)RUPDWRIQHWZRUNVXSHUYLVLRQPHVVDJHV
1RGHVXSHUYLVLRQPHVVDJHV
The format of event session supervision messages is Defined in 5.7.2.
The format of LonTalk Network Management Message “Query Status” is defined

e.g. in Echelon: “LonTalk Protocol Specification”.
The format of SNVT_obj_status is Defined in 5.6.1.6.
6WDWXVDQGHUURUPHVVDJHV
The format of status and error messages (see 4.6.3.2):

- device coldstart
- device warmstart
- device error warning
- device error and
- device event buffer overflow
is “Single point of information with time tag” as Defined in chapter 5.4.3.
The type of the message is Defined by object number (Object No.) of the
message, see next table.
Message Object number

coldstart 1
warmstart 2
error warning 3
error 4
event buffer overflow 5
Table 3 . Object numbers of status and error messages.
PRG 3DJH
196 / 216 6SHF&/$
)RUPDWRIWLPHV\QFKURQLVDWLRQPHVVDJHV
19W\SH 19BFORFN
Description:
The NV_clock is an information object that represents the absolute time of day
and date. This NV is used for time synchronisation.
Coding:
1 0 selector msb default selector value is 2FFFH

selector lsb
1 year (msb) year in binary format
2 year (lbs)
3 month month in binary format
4 day day in binary format
5 hour hour in binary format
6 minute minute in binary format
7 second second in binary format
8 ms and 100 us (msb) milliseconds and hundreds of microseconds as
9 ms and 100 us (lsb) 16-bit binary number
Note:
The time in NV_clock contains a time which includes propagation time

compensation. See chapter 4.6.4 for more details.
PRG 3DJH
197 / 216 6SHF&/$
19W\SH 19BFORFNBZDUQLQJ
Description:
The NV_clock_warning an information object that specifies the number of

milliseconds between sending of NV_clock_warning and NV_clock.
After receiving the NV_clock_warning the node should stop sending normal
priority messages. This is to guarantee that the receive buffers in all the nodes are
empty, at the time of sending NV_clock. If the receive buffers are empty, then
the delay between receiving of the NV_clock the processing of it is as short as
possible.
Coding:
1 0 selector msb default selector value is 2FFEH

selector lsb
delay, byte 1 delay between warning and clock (30...100 ms)
PRG 3DJH
198 / 216 6SHF&/$
19W\SH 19BWLPH
Description:
The NV_time is an information object that represents the absolute time of day and
date. This NV is used for time synchronisation. The time is presented in
CP56Time 2a format [IEC4].
Coding:
1 0 selector msb default selector value is 2FF7H

selector lsb
Milliseconds (MSB)
Milliseconds (LSB)
TV RES Minutes CP56Time 2a
SU RES Hours
Res (day of week) Day of month
Res Months
Res Years
&37 9DOXH 'HILQLWLRQ
Millisconds 0...59 999 Milliseconds up to the minute

Minutes 0...59
TV 0 Time is valid (unit is synchronized and has a time)
1 Time is not valid (unit is not synchronized)
Hours 0...23
SU 0 Standard time (= „winter“ time)
1 Summer time
Day of month 1...31
Months 1...12
Years 0...99 years within a century
RES Reservation bits (not used); Day of week is not supported
PRG 3DJH
199 / 216 6SHF&/$
19W\SH 19BV\QFBWLPH
Description:
The NV_sync_time is an information object that represents the absolute time of
day and date.
This NV is used as a base NV for VATS time synchronisation see [LCMF].
7 6 5 4 3 2 1 0
1 d selector (msb)
selector (lsb)
1 year (msb) year in binary format
year (lsb)
2 month month in binary format
3 day of month day in binary format
SU
4 hours hour in binary format
IV
5 minutes minute in binary format
seconds seconds in binary format
6 ms (msb) milliseconds
7 ms (lsb) in binary format
8 res µSec (msb) µSeconds
9 µSec [lsb] in binary format
19BV\QFBWLPH Value Definition

d direction
0 the message is addressed to an input network variable
(message is a nv update message or a response to a poll)
year 0...9999
month 0..12
day 1..31
SU Standard/Summertime
0 standard local time
1 daylight saving time
hours 0..23
IV Invalid/Valid
0 valid
1 invalid
minutes 0..59
seconds 0..59
res
Bit 7 Bit 6 Bit 5 Resolution of the
Clock Master
0 0 0 1 µsecond
0 0 1 10 µsecond
0 1 0 100 µsecond
0 1 1 1 millisecond
1 0 0 10 millisecond
1 0 1 100 millisecond
1 1 0 1 second
1 1 1 not used
milliseconds 0..999
µSeconds 0..999
1RWHThe time is always transfered as local time (winter- or summertime)
PRG 3DJH
200 / 216 6SHF&/$
)RUPDWRI7UDQVSDUHQW'DWDQHWZRUN9DULDEOH
19W\SH 19BWBGDWD
7 6 5 4 3 2 1 0
1 0 selector msb
selector lsb
1 contents user specific
2 ..
3 ..
4 ..
5 ..
.. .. ..
.. .. ..
30 contents user specific
1RWH The NV_t_data is used for application specific transmission.
PRG 3DJH
201 / 216 6SHF&/$
5HIHUHQFHV
[FTLW] Echelon: “File transfer, LonWorks Engineering Bulletin, April 1993.
[IEC3] IEC 870-5-3, International Standard, First Edition 1992-9, Part 5 Transmission
protocols, Section 3 : General Structure of application data
protocols, Section 4 : Definition and coding of application information elements
protocols, Section 5 : Basic application functions
protocols, Section 101 : Companion standard for basic telecontrol task
[IEC103] IEC 60870-5-103/FDIS, International Standard, Part 5-103

Transmission protocols, Companion standard for the informative interface of
protection equipment.
[LALI] LonMark Application Layer Interoperability Guidelines, Version 2.0, document

number 078-0120-01B. Echelon corporation 1995.
[LCMF] Lon Clock Master Functional Specification Version B, 07.01.98,

O.Ala-Penttilä/W.Kozlowski, ABB Transmit Oy.
[LHAPG] LonWorks Host Application Programmer’s Guide. Revision 2. Echelon

Corporation, 1993.
[LHWG] Lon Hardware Guideline, Version 1.0, CHTET . Spec-98/9CLA301006, 1998.
[LIOG] LonMark Layers 1-6 Interoperability Guidelines, Version 1.3, document number
078-0014-01D. Echelon corporation 1994.
[LNMI] LonMark Network Management Interoperability Guidelines. Echelon corporation

1995.
[LPDB] The 1995 Echelon LonWorks products databook. Echelon corporation 1994.
[LPS] LonTalk Protocol Specification, Version 3.0, document number 078-0125-01A.

Echelon Corporation, 1994.
[LSNMP] The SNVT Master List and Programmer's Guide. Echelon corporation, January
1995.
[LTPT] LonTalk Protocol Specification, document number 078-0125-01A.

Echelon Corporation
[LTRTM] LonTalk Response Time Measurements, LonWorks Enginering Bulletin. Echelon

Corporation, March 1992.
[MOTD] Neuron Chip Distributed Communications and Control Processors MC143150,

MC143120. Motorola Semiconductor Technical Data. Motorola Inc 1994
[SPCP] SPA-bus Communication Protocol V2.4, document number 34 SPACOM 3EN1C.

ABB Asea Brown Boveri, 1992.
Date 98-09-08 Pages 216

[SPLGW] SPA-ZC 100, LON/SPA-gateway User’s Guide. ABB Asea Brown Boveri, 1994.
[TSYPY] Pyramid : Panorama Station Automation Time Synchronization Description,

TN-NST98/xxx,Preliminary, 98.06.05, E.Pou, ABB CHNET
PRG 3DJH
203 / 216 6SHF&/$
5HYLVLRQ,QIRUPDWLRQ
The following information has been changed from the previous version:
Section Description Date/Dept/Sign
1.0 All sections Original version 19.10.1995

O.Vähämäki /BU P , L.
Andersson /CHNET,
C. Byman /SENET, D.
Kronman /FIMIT,
M. Mueller /DENET, A.
Sollie /SENET,
A. Stoor/FIMIT, K. Svensson
/SENET,
All sections -New style used in document format. A 02.04.1996
document header and footer was added. The O. Vähämäki /BU P
word document was split into a master document
and several subdocuments.
-Chapter 2.3.2.1 was renamed to “Introduction”.
-General text and figure 12 decribing event
transmission using the sliding window protocol
was added to chapter 2.3.2.1.
-In chapter 2.3.8.1 sentence “The cure for this...”
was replaced with “The cure for this is to
implement a transport protocol on top of the
LonTalk application layer”. The change was
done to crarify that no changes have been done
to the LonTalk protocol’s transport or session
layer.
-Chapter 3.6.2.4 “Transmission control
messages with data” was merged to chapter
3.6.2.3. “Transmission control messages”.
-Chapter 3.6.2.5 was renumbered to 3.6.2.4.
-Credit field added to message formats in
chapters 3.3.2.1, 3.6.2.3.1, 3.6.2.3.2, 3.6.2.3.3,
3.6.2.3.4.
-Message code for “Query Extended Address”
message was changed to 3CH in chapter
3.6.1.2.
-Message format of positive response to “Query
Extended Net Variable Config message” was
corrected in chapter 3.6.1.4, the response
should not contain nv_index, nv_index_high or
nv_index_low.
-Appendix 4 was added to the document.
-A revision number indicating the latest editorial
revision of the current version of the document
was added to the document.
-Chapter “Versions of the document” was
removed and the same information is now given
in chapter “Revision information”.
Appendix 3 Error was corrected: correct default selector 7.10.1996/OV

value for NV_clock is 2FFFH and for
NV_clock_warning it is 2FFEH.
3.3.3.3.3, Bitfields in message format descriptions 7.10.1996/OV

3.3.3.4.5...3.3.3.4.12 indicating the DMCD type were corrected.
3.3.3.3.10, 3.6.4.3 Bit name IV chaged to TV in the message format 7.10.1996/OV
descriptions.
3.6.1.3 Clarifications for the use of Update and Query 7.10.1996/OV
Extended Network Variable Configuration Table
PRG 3DJH
204 / 216 6SHF&/$
messages were added.
3.6.2.3.4 Chapter was removed. The described message 7.10.1996/OV
is not needed.
2.3.2 Updated pictures and text describing the sliding 7.10.1996/Harri Sirkkala
window protocol.
renumbering of the structure was changed due to add ASDU 08.12.97/DEACE/A.Janz
different chapters and for Command Handling, Command Transfer
File Transfer 08.12.97/DEACE/A.Janz
Transparent Data Transfer, NV_t_data 08.12.97/DEACE/A.Janz
Transfer of Counter Values 08.12.97/DEACE/A.Janz
Time Synchronisation, NV_time_sync,SNVT 08.12.97/DEACE/A.Janz

8,22
added Types new ASDU Types 08.12.97/DEACE/A.Janz
CMD 45-47, 50-51,101,111
Events 140-144
Filetransfer 120,122-126
Diagnosis 201
Transparent Data 231
ABB application layer description renewed 14.01.98/DEACE/A.Janz
A. 4.3.2.8, 4.3.2.8.1, 4.3.2.8.2 added for 20.08.98/02.09.98

description of setup session establishment and /DEACE/A.Janz/W.Dieterle
closure.
B. 5.4.4.2.1.7, 5.4.4 DMCD type 111 = P_ME_NB
Attribute command for measured values
removed
C. 5.4.4.1.32 QPM (Parameter of measured value)
removed
D. 5.4.2.3 COT valid and not blocked process
object value available introduced
E. 5.4.4 DMCD type 110 = General Object
Handling Command introduced
F. 5.4.4.1.4 AVA introduced
G. 5.4.4.1.44 TOH introduced
H. 5.4.4.1.45 TOV introduced
I. 5.4.4.2.1.10 DMCD type = 230 = C_SS_NA,
Setup Session command/response added
J. 5.4.4.1.41 SSQ (Setup Session Qualifier) added
K. 4.1.8.4 Network PDU/DPU Format sentence If
TranData = 1: This is last message in current
window. Send ACK immediately
L. Fig 32 changed Fig 33 & 34 new Example of
Event Data message in monitoring direction
with one ASDU = one data signal type and SQ
= 0 with three information objects (ASDU
without time tag
M. Type 231 Transparent Data , 34 changed to 35
N. 4.3.3.2 Command transfer as SPA new Sentence
:
If the SPA messages to be sent is longer that
what is allowed by the LON telegram length,
then fragmentation/defragmentation is done as
described in [SPCP]. Each fragment as specified
in [SPCP] is sent as a transparent SPA message
over LON
O. 4.3.3.1 Commands, sentence changed, new table
P. 5.7.2 Session Control messages / 5.7.3
Transport Control Messages bit 7 from
messsage type replaced by d, for direction , d =
PRG 3DJH
205 / 216 6SHF&/$
1 server to client , d = 0 client to server
Q. Table 7 : Network Variables with selectors base
types , extended and base type added
R. 3.2.1 timing parameters changed to
1HXURQFKLSSDUDPWHUVDQGEXIIHUFRXQWVand
new configuration parameters
S. 6HUYLFHVDQGDGGUHVVLQJIRUPDWVXVHGLQ
6XEVWDWLRQDXWRPDWLRQ changed into 4.1.4.
Service types, addressing formats and timer
values
T. Table 3 Summary of the use of transport
services and addressing formats removed
U. Short description of used sliding window
protocol timers moved into own paragraph 4.
4.1..8.8. Transport protocol timers
V. Reference for the Time synchronisation
document added
W. Added Note to GI and ES cmd1RWH7KHXQLW
DGGUHVVGRHVQRWFRQWDLQDYDOLGYDOXHDQGWKH
LPSOHPHQWDWLRQLVRQHHYHQWVHVVLRQWRRQH
SK\VLFDOQRGHQRGH removed
X. 5.4.4 Type_Id changed to DMCD Type : Table

4
Y. NFD in 5.4.4.1.39 SOFD = Status of File or

Directory added
Z. 5.4.4.2.1. DMCD type 129 , sentence APDU :
M_SP_N Single-point information without
Time Tag removed
AA. 5.4.2.1 Figure 36 Sentence added : “Note : If a

single ASDU_Type with time tag is packed in
that manner one time tag is at the end of the
ASDU and valid for all information elements´
BB. New DMCD Type 154 Event of Protection

Equipment with time tag introduced
CC. New DMCD Type 155 Packed Start Event of

protection equipment with time tag introduced
DD. New DMCD Type 156 Packed Output Circuit

Information of prtection equipment introduced
EE. New CP16 = Two Octet Binary Time

introduced
FF. New OCI = Output circuit information of

protection equipment introduced
GG. New SPE = Start events of protection equipment

introduced
HH. New QDP = Quality Descriptor for events of

Protection Equipment introduced
II. New SEP = Single-Event of protection

equipment
JJ. New DMCD Type 49 ,Set-Point Command,

Signed Integer 16 bit introduced
PRG 3DJH
206 / 216 6SHF&/$
KK. New DMCD Type 48 Set-Point Command,

Signed Integer 32 bit introduced
LL. New VAI32 = Signed Integer value 32 bit

introduced
MM. DMCD type =138 , Measured value, short

floating point with Time Tag
New COT 5 (requested) added
NN. New DMCD type =148, Measured value, signed

integer 32 bit with Time Tag introduced
OO. Appendix 3 Table 6 nv_alarm changed to

nv_clock_sync_alarm
PP. 5.4.4.2.3.5 Type 125 Segment Note changed to

“The Type 125 is transferred with a fixed length
always 31 Octets with SQ=0, ASDU_Number =
1”
QQ. 5.4.4.2.3.6 Type 126 Directory Octet changed to

ASC with reference
Note changed to
“The Type 126 is transferred with a fixed length
always 20 Octets with SQ=0, ASDU_Number =
1”
RR. 5.4.4.2.1.8 Type 101 COT 10 Activation

Termination removed
SS. NEW LOV = Length of Attribut Value

introduced
TT. 4.3.3.2 Commands transfer as SPA..

Sentence : “Commands are transferred as….”
removed
UU. 4.3.4 File Transfer

Word “ mechanismen” changed to mechanism
VV. 4.3.6 Parameter Transfer

Sentence” using Parameter ..” removed
WW. 5.7.2.1 Event Session setup messages changed

to 6HVVLRQVHWXSPHVVDJHV
Sentence “Format for ES…” removed
Sentence “The format …” changed
XX. NEW DMCD Type =147 = M_MEI_N,

Measured value, signed integer 32 bit without
Time Tag
YY. Appendix 3 Table 6 nv_time_zone signed long

changed to SNVT_count_inc
ZZ. New Reference [LHWG] Lon Hardware

Guideline, Version 1.0, CHTET . Spec-
98/9CLA301006, 1998
AAA. Appendix 5 Timing removed
BBB.3.1.2 Timing parameters remved
CCC.New in Appendix 5 Neuron Chip and buffer
PRG 3DJH
207 / 216 6SHF&/$
counts
DDD. 3. Physical Structure removed, will be in

Lon Hardware Guidelines
EEE. 3.1 Connection possibilities removed will be in

Lon Hardware Guidelines
FFF. 3.1.1 Specification of LON-bus fibre optic

interface removed will be in Lon Hardware
Guidelines
GGG. 3.1.3 Device interface options removed

will be in Lon Hardware Guidelines
HHH. 3.2 Configuration structures changed into

Chapter 3.0 Configuration structures,
III. 3.2.1 – 3.2.7 changed to 3.1- 3.7
JJJ. 4.24 Guidelines for setting the application layer

timers changed into Guidelines for setting
Neuron chip parameter and buffer counts
KKK. 4.1.8.1 new sentence “The adressing
scheme for the application protocol is used as
described in ...”
LLL. 5.4.2.5.1 Unit No “1RWH : Its not mandatory for

a client to support several logical units on one
physical device” added
MMM. App3 nv_sync_time has base

NV_time_sync NV_sync_time
NNN. App6 File Transfer, Commitment “Parallel

file...” and “Ist not allowed..” are replaced by
the sentences “One originator..”, “Diffrent..”
PRG 3DJH
208 / 216 6SHF&/$
$SSHQGL[3HUIRUPDQFHRI/21QHWZRUNLQWHUIDFH
Some performance figures (as given in Echelon’s LonWorks Product Databook) of different types of
network interfaces is collected to the following table:
Type of interface Throughput, messages/s Throughput, messages/s

Unacked messages Acked messages
8-byte data 32-byte data 8-byte data 32-byte data
Parallel (MIP/P50, host 25 Mhz 386) 289 260 103 94
Parallel (MIP/P20, host 25 Mhz 386) 205 170 74 68
Dual-ported RAM (MIP/DPS, host 25 Mhz 386) 396 364 103 94
PCLTA (60 Mhz Pentium, performance per channel) 476 400 100 92
SLTA (serial interface 115,2 kbit/s, host 25 Mhz 386) 71 56 71 59
Note: When an unacknowledged message is sent only one message packet is sent over the bus per
message. When an acknowledged message is sent two message packets are sent over the bus: the
message packet itself and the acknowledgement packet.
In actual implementations including the host software the performance figures may be different than
the ones given in the above table.
PRG 3DJH
209 / 216 6SHF&/$
$SSHQGL[*HQHUDO/210HVVDJH)RUPDW
The following message formats are used for sending application messages containing either a Network Variable or
Explicit Message.
The following tables describe the different fields of a LonTalk message:
Preamble:
Preamble: BitSync 6...n ByteSync 1
Common header:
Prior 1 AltPath 1 Delta_BL 6
Version 2 PDUFmt 2 AddrFmt 2 Length 2 PDUFmt specifies TPDU, SPDU, AuthPDU or APDU
Addressing fields (five different address field options):

AddrFmt=0 AddrFmt=1 AddrFmt=2a AddrFmt=2b AddrFmt=3
broadcast multicast unicast multicast ack unicast
ScrSubnet 8 ScrSubnet ScrSubnet SrcSubnet ScrSubnet
1 ScrNode 7 1 ScrNode 1 ScrNode 0 ScrNode 1 ScrNode
DstSubnet 8 DstGroup DstSubnet DstSubnet DstSubnet
1 DstNode 1 DstNode Neuron ID
Group Neuron ID
GroupMemb Neuron ID
Neuron ID
Neuron ID
Neuron ID
Domain ID:
Domain 0/8/24/48 0,8,16 or 48 bits (0,1,2 or 6 bytes) defined by “Length”
PDU header:
Auth 1 xPDUtype 3 Trans_No 4 PDU header for TPDU, SPDU or AuthPDU
Data part:
Destin&Type 8/16
Data 0...n
Checksum:
CRC msb 1
CRC lsb 1
Note: In the tables above, a number after a field name specifies the field size in bits.
PRG 3DJH
210 / 216 6SHF&/$
Explanations for message fields:
- Preamble, BitSync = string of logical 1’s, minimum length 181 microseconds or six bits
- Preamble, ByteSync = 1-bit field, logical 0, specifying the end of the preamble
- Prior = 1-bit field specifying the priority of this MPDU: 0 = normal, 1 = high
(MPDU = MAC protocol data unit, or frame; MAC Medium Access protocol layer)
- AltPath = a 1-bit field specifying the channel to use. This is a provision for tranceivers that have the ability to transmit on two different
channels and receive on either one without prior configuration. The transport layer sets this bit for the last two retries, or the MAC sublayer can
be configured to always transmit on the alternate path.
- Delta_BL = a 6-bit field; specifies channel backlog increment to be generated as a result of delevering this MPDU
- Version = a 2-bit field; protocol version, 0...3
- PDU Fmt = a 2-bit field; Protocol Data Unit format;
0 = TPDU, Transport Protocol Data Unit, or a message/ack;
1 = SPDU, Session Protocol Data Unit, or request/response;
2 = AuthPDU, Authentication Protocol Data Unit;
3 = APDU, Application Protocol Data Unit
- AddrFmt = a 2-bit field; Logical Address Format;
0 = broadcast, domain wide or by individual subnet;
1 = multicast, message or reminder;
2: 2a = unicast message, reminder or acknowledgement;
2: 2b = multicast acknowledgement (msb-bit in ScrNode field is 0);
3 = unicast message or reminder
- Length = length of Domain identification; 0 = 0 bits; 1 = 8 bits; 2 = 24 bits; 3 = 48 bits
- ScrSubnet = Source Subnet, subnet number of the sending node
- ScrNode = Source Node, node number of the sending node
- DstSubnet = Destination Subnet, number of the destination subnet
- DstNode = Destination Node, number of the destination node
- DstGroup = number of the Destination Group
- Neuron ID = 6 byte Neuron ID of the receiving node’s Neuron chip
PRG 3DJH
211 / 216 6SHF&/$
- Domain = Domain identification of the sending node and receiving node(s)
- Auth = 1-bit field; specifying the use of authentication; 0 = not used; 1 = used
- xPDUtype = 3-bit field; Transaction/Session/Authentication Protocol Data Unit type;
Transaction Protocol Data Unit types:
0 = Acknowledged Message;
1 = Unacknowledged-repeated Message;
2 = Akcnowledgement;
4 = Reminder;
5 = Message-Reminder
Session Protocol Data Unit types:
0 = Request;
2 = Response;
4 = Reminder;
5 = Message-Reminder
Authentication Protocol Data Unit types:
0 = challenge;
2 = reply
- Trans_No = 4-bit field; transaction number
- Destin&Type = 8- or 16-bit field;
Network Variables: 16 bit value >= 8000H, 14 lsb bits specifying the NV selector;
Explicit messages: 8 bit value < 80H, 7 lsb bits specifying the message code;
- Data = 0...31/229 bytes containing message data bytes (max. 31 for NVs)
- CRC = 16-bit CRC checksum, CCITT CRC-16
PRG 3DJH
212 / 216 6SHF&/$
Examples:
Unicast (subnet/node) address, no domain id, acknowledged service:

Preamble: BitSync ByteSync 1

Version 2 PDU Fmt 2 (=0) AddrFmt 2 (=2) Length 2 (=0)
ScrSubnet 8
1 ScrNode 7
DstSubnet 8
1 DstNode 7
Auth 1 TPDUtype 3 (=0) Trans_No 4
Destin&Type 8/16
Data 0...n
CRC msb
CRC lsb
Multicast (group) address, no domain id, acknowledged service:


ScrSubnet 8
1 ScrNode 7
DstGroup 8
Destin&Type 8/16
Data 0...n
CRC msb
CRC lsb
Broadcast address, no domain id, unacknowledged, repeated service:


ScrSubnet 8
1 ScrNode 7
DstSubnet 8
Destin&Type 8/16
Data 0...n
CRC msb
CRC lsb
Broadcast address, no domain id, unacknowledged service:


ScrSubnet 8
1 ScrNode 7
DstSubnet 8
Destin&Type 8/16
Data 0...n
CRC msb
CRC lsb
PRG 3DJH
213 / 216 6SHF&/$
$SSHQGL['HIDXOWQHWZRUNYDULDEOHVHOHFWRUYDOXHVDQGLQGH[HV
For network variables used for time synchronisation and file transfer there has been made the following
assumptions what comes to network variable index or selector value. This has been done to enable clock
synchronisation and file transfer to start without network variable binding.
Even though default selector values have been given to network variables, the values can be changed in the normal
way by using network management tool (e.g. when using a file transfer program, which make no assumptions
about the network variable selectors.)
'HVFULSWLRQ %DVH19W\SH GLUHFWLRQ 19LQGH[ VHOHFWRUKH[
nv_clock NV_clock in/out -- 2fff

nv_clock warning NV_clock_warning in/out -- 2ffe
file sender req in 254 2ffd
file sender pos in 253 2ffc
file sender status out 252 2ffb
file receiver req in 251 2ffa
file receiver pos in 250 2ff9
file receiver status out 249 2ff8
file initiator sender req out 248 2ffd
file initiator sender pos out 247 2ffc
file initiator sender status in 246 2ffb
file initiator receiver req out 245 2ffa
file initiator receiver pos out 244 2ff9
file initiator receiver status in 243 2ff8
nv_time NV_time in/out -- 2ff7
nv_sync_time NV_time_sync in/out -- 2ff6
nv_time_stamp SNVT_time_stamp in/out -- 2ff5
nv_sync_pulse SNVT_state in/out -- 2ff4
nv_pulse_time NV_time_sync in/out -- 2ff3
nv_pattern_time NV_time_sync in/out -- 2ff2
nv_ref_time NV_time_sync in/out -- 2ff1
nv_sync_mode SNVT_state in/out -- 2ff0
nv_t_data NV_t_data in/out -- --
nv_time_zone SNVT_count_inc in/out -- --
nv_invalid_ref SNVT_lev_disc in/out -- --
nv_clock_sync_alarm SNVT_alarm in/out -- --
nv_warn_interval SNVT_count in/out -- --
nv_delay_comp SNVT_count in/out -- --
7DEOH5HVHUYHG1HWZRUN9DULDEOHZLWKWKHLUEDVHW\SHVVHOHFWRUYDOXHVDQGLQGH[HV
PRG 3DJH
214 / 216 6SHF&/$
$SSHQGL[6XPPDU\RIQHWZRUNYDULDEOHW\SHV
The following network variable types are referenced in this document.
Type name Type Usage Remark

number
SNVT_x_f .... Analog values Floating point analog values.
SNVT_count 8 Configuration Clock Master Delay compensation adjustment RER111
SNVT_lev_disc 22 Diagnostic Clock Master Supported by LonClock-Master Card
SNVT_state 83 Digital data 1...16 bits of digital data
SNVT_time_stamp 84 Time synchronisation Supported by Lon Clock Master Card
SNVT_alarm 88 Alarms LonMark compatible alarm message type.
SNVT_object_request 92 Request for status of an object Required in LonMark compatible nodes.
SNVT_object_status 93 Status of an object Required in LonMark compatible nodes.
NV_t_data 247 Transparent Data 248 bit for Transparent data
NV_time_sync 248 Time synchronisation VATS Time synchronisation
NV_time 249 Clock synchronisation
NV_control 250 Control command Can be bound with SNVT_state
NV_bit_write 251 Bit write/reset Can be bound with SNVT_state
NV_32b_analog 252 Analog values Signed 32-bit integer, scale 1000
NV_16b_analog 253 Analog values Signed 16-bit integer, scale 100
NV_clock_warning 254 Clock synchronisation
NV_clock 255 Clock synchronisation
7DEOH6XPPDU\RIQHWZRUNYDULDEOHV
For network variables used in LonTalk file transfer see Chapter 10 Table 4 and chapter 2.3.7.
1RWH Network variable types having name beginning with letters “SNVT” are standard network variable types.
Network variable types having name beginning with “NV” are ABB specific network variable types. (See chapter
2.1.5 for more details about network variable naming conventions.)
PRG 3DJH
215 / 216 6SHF&/$
$SSHQGL[1HXURQFKLSSDUDPHWHUVDQGEXIIHUFRXQWV
5HDGRQO\GDWDVWUXFWXUH
For all the nodes in a LON-bus the following parameters are to be used in “Read-only structure” of the Neuron
chips.
receive_trans_count 15 ; mandatory, to support maximum number of concurrent receivetransactions
net_buf_in_cnt 15 ; minimum value
all buffer sizes 66 bytes ; minimum buffer size for all types of buffers
&RQILJXUDWLRQVWUXFWXUH
For the nodes in the fibre-optic LON-bus the following parameters are to be used in “Configuration structure” of
the Neuron chips.
preamble_length 6 ; mandatory, 240us
packet_cycle 4 ; mandatory
beta2_control 0 ; mandatory, 24us
xmit_interpacket 0 ; mandatory
recv_interpacket 0 ; mandatory
node_priority 0 ; mandatory, this can only differ from 0, if priority scheme is used
channel_priority 30 ; minimum, must be equal in all nodes in the system, can be increased
according priority scheme demands
preemption_timeout 5 ; mandatory, 10s
collision_detect 1 ; mandatory,
bit_sync_threshold 0 ; mandatory, 4 bits
cd_to_end_packet 1 ; mandatory,
cd_tail 1 ; mandatory
cd_preamble 0 ; mandatory, collision detect decision not yet after preamble

non_group_timer 128ms ; mandatory, minimum value, timer for duplicate detection in unicast
and broadcast receiving
To minimise the risk of misunderstandings the configuration structure is represented here as hex values. Notice that
location string is here 6 blanks.
00 00 20 20 20 20 20 20 05 2E 06 04 00 00 00 00 1E 80 06 00 00 00 00 00 05
PRG 3DJH
216 / 216 6SHF&/$

Lag 14

Uploaded by

Copyright:

Available Formats

Lag 14

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lag 14

Uploaded by

Copyright:

Available Formats

LON Application Guidelines

for Substation Automation

Date 98-09-08 Pages 216

Possible comments to this paper should be sent to :

4.3.2.5 Establishing the event session .......................................................................................................................................53

5.2.2.2 Network management commands .................................................................................................................................88

5.4.4.1.46 SPE = Start events of protection equipment.......................................................................................................123

5.5.2.1 LSG event type 0 = LSG SPA event ...........................................................................................................................170

 5(9,6,21,1)250$7,21  

 $33(1',;'()$8/71(7:25.9$5,$%/(6(/(&7259$/8(6$1',1'(;(6 

 $33(1',;6800$5<2)1(7:25.9$5,$%/(7<3(6  

 $33(1',;1(8521&+,33$5$0(7(56$1'%8))(5&28176 

Usually a LON-bus system, which is used for Substation Automation purposes

Interfaces to other types of network cabling (e.g. transformer isolated twisted

The only monitoring device of a small system is usually a gateway

26 relays or control units

Figure 1. System example: 1 star-coupler RER111, 1 monitoring device, 26

25 relays or control units

Figure 2. System example: 1 star-coupler RER111, 2 monitoring devices, 25

Using three star-coupler of type RER111 a system with up to 67 relays and

Star coupler Star coupler

22 relays or control units 22 relays or control units

Figure 3. System example: 3 star-couplers RER111, 2 monitoring devices, 67

In this configuration a domain broadcasted message may arrive to the monitoring

Fiber optic LON Router Twisted pair LON

Protection and Control devices Industrial LON devices

Figure 4. System example: connection to an industrial control system.

In figure 6 there is a star-coupler RER111 with router card. Interface to twisted

Vertical communication describes communication between the monitoring

Protection and Control devices Industrial LON devices

Figure 5. Vertical communication.

Horizontal communication describes communication between the protection and

Protection and Control devices Industrial LON devices

Figure 6. Horizontal communication.

LSG communication describes communication used with LON/SPA-gateways.

Protection and Control devices Industrial LON devices

Figure 7. LSG communication.

Interoperable communication describes communication with nodes using protocol

Examples of this communication could be communication with industrial

Protection and Control devices Industrial LON devices

Figure 8. Interoperable communication.

The LonTalk protocol employs a data oriented application protocol. In this

Network variables are addressed on application level using network variable

The following transport/session layer services are possible in the protocol:

In all of the addressing formats a domain id of 1, 3 or 6 bytes may be used or it

1RWH Domain id is not needed/used in Substation Automation applications.

The addressing limits given by the message formats and implementation

The following figure shows transactions diagrams of different message types.

NV Éxplicit message (code 41H)

Éxplicit message (code 43H) Transfer of transparent

Transfer of LSG Note: Messages marked with “ack” in these pictures

Figure 9. Transaction diagrams for different message types.

Each network variable has a type number and a name as follows:

With max. messages length of 48 bytes the max. length of communication

The maximum length of message is limited due to the following reasons:

Specification of the file transfer protocol can be found in [FTLW].

LonTalk file transfer protocol’s file directory information

Note: File index 0 is reserved for LonMark Configuration Parameter Template

5(9,6,21,1)250$7,21

$33(1',;'()$8/71(7:25.9$5,$%/(6(/(&7259$/8(6$1',1'(;(6

$33(1',;6800$5<2)1(7:25.9$5,$%/(7<3(6

$33(1',;1(8521&+,33$5$0(7(56$1'%8))(5&28176

1RWH Domain id is not needed/used in Substation Automation applications.

VFRQQUHVin response to request.