IO-Link Interface and System

Specification

Version 1.1 November 2010 Order No: 10.002

IO-Link Interface and System Specification

Version 1.1

_________________________________________________________________________________________________________

File name: IOL-Interface-Spec_10002_V11_Nov10

Prepared, approved and released by the IO-Link Consortium. The IO-Link technology is currently going to be standardized as IEC 61131-9. The IO-Link Consortium is a D-Liaison member in the corresponding working group. Any comments, proposals, requests on this document are appreciated. Please use www.io-link-projects.com for your entries and provide name and email address. Login: IO-Link-V11 Password: Report
Important notes: NOTE 1 The IO-Link Consortium Rules shall be observed prior to the development and marketing of IO-Link products. The document can be downloaded from the www.io-link.com portal. NOTE 2 Any IO-Link device shall provide an associated IODD file. Easy access to the file and potential updates shall be possible. It is the responsibility of the IO-Link device manufacturer to test the IODD file with the help of the IODD-Checker tool available per download from www.io-link.com. NOTE 3 Any IO-Link devices shall provide an associated manufacturer declaration on the conformity of the device with this specification, its related IODD, and test documents, available per download from www.io-link.com. Disclaimer: The attention of adopters is directed to the possibility that compliance with or adoption of IO-Link Consortium specifications may require use of an invention covered by patent rights. The IO-Link Consortium shall not be responsible for identifying patents for which a license may be required by any IO-Link Consortium specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. IOLink Consortium specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents. The information contained in this document is subject to change without notice. The material in this document details an IO-Link Consortium specification in accordance with the license and notices set forth on this page. This document does not represent a commitment to implement any portion of this specification in any company's products. WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, THE IOLINK CONSORTIUM MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL INCLUDING, BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR PARTICULAR PURPOSE OR USE. In no event shall the IO-Link Consortium be liable for errors contained herein or for indirect, incidental, special, consequential, reliance or cover damages, including loss of profits, revenue, data or use, incurred by any user or any third party. Compliance with this specification does not absolve manufacturers of IO-Link equipment, from the requirements of safety and regulatory agencies (TV, BIA, UL, CSA, etc.).

is registered trade mark. The use is restricted for members of the IO-Link Consortium. More detailed terms for the use can be found in the IO-Link Consortium Rules on www.io-link.com.
Conventions: In this specification the following key words (in bold text) will be used: may: indicates flexibility of choice with no implied preference. should: indicates flexibility of choice with a strongly preferred implementation. shall: indicates a mandatory requirement. Designers shall implement such mandatory requirements to ensure interoperability and to claim conformity with this specification.

Publisher:

IO-Link Consortium
Haid-und-Neu-Str. 7 76131 Karlsruhe Germany Phone: +49 721 / 96 58 590 Fax: +49 721 / 96 58 589 E-mail: info@io-link.com Web site: www.io-link.com No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher.
_________________________________________________________________________________________________________

Copyright IO-Link Consortium 2010 - All Rights Reserved

Page

of

253

61131-9/WD V0.5 IEC

Working Draft

CONTENTS

FOREWORD.......................................................................................................................15 0 Introduction ..................................................................................................................17 0.1 General ...............................................................................................................17 0.2 Patent declaration ...............................................................................................18 Scope ..........................................................................................................................19 Normative references ...................................................................................................19 Terms, definitions, symbols, abbreviated terms and conventions ...................................20 Overview of SDCI (IO-Link TM ) .......................................................................................28 Physical Layer (PL) ......................................................................................................34 Standard Input and Output (SIO)...................................................................................48 Data link layer ..............................................................................................................48 Application layer ...........................................................................................................92 System management (SM) .......................................................................................... 111

1 2 3 4 5 6 7 8 9

10 Device........................................................................................................................ 139 11 Master........................................................................................................................ 156 Annex A (normative) Codings, timing constraints, and errors ............................................. 182 A.1 General structure and encoding of F-sequences .......................................................... 182 A.1.1 Overview ........................................................................................................... 182 A.1.2 F-sequence control (FC) .................................................................................... 182 A.1.3 Checksum / F-sequence type (CKT) ................................................................... 183 A.1.4 User data (PD or OD) ........................................................................................ 183 A.1.5 Checksum / status (CKS) ................................................................................... 184 A.1.6 Calculation of the checksum .............................................................................. 184 A.2 F-sequence types ....................................................................................................... 185 A.2.1 Overview ........................................................................................................... 185 A.2.2 F-sequence TYPE_0 .......................................................................................... 185 A.2.3 F-sequence TYPE_1_x ...................................................................................... 186 A.2.4 F-sequence TYPE_2_x ...................................................................................... 187 A.2.5 F-sequence type 3 ............................................................................................. 190 A.2.6 F-sequence type usage for STARTUP, PREOPERATE and OPERATE modes..... 190 A.3 Timing constraints ...................................................................................................... 192 A.3.1 General ............................................................................................................. 192 A.3.2 Bit time.............................................................................................................. 192 A.3.3 Character transmission delay of Master (ports)................................................... 192 A.3.4 Character transmission delay of Devices ............................................................ 192 A.3.5 Response time of Devices.................................................................................. 192 A.3.6 F-sequence time ................................................................................................ 192 A.3.7 Cycle time ......................................................................................................... 193 A.3.8 Idle time ............................................................................................................ 193 A.4 Errors and remedies ................................................................................................... 194 A.4.1 UART errors ...................................................................................................... 194 A.4.2 Wake-up errors.................................................................................................. 194 A.4.3 Transmission errors ........................................................................................... 194

Working Draft

61131-9/WD V0.5 IEC

A.4.4 Protocol errors................................................................................................... 194 A.5 General structure and encoding of ISDUs.................................................................... 195 A.5.1 Overview ........................................................................................................... 195 A.5.2 Service.............................................................................................................. 195 A.5.3 Extended length (ExtLength) .............................................................................. 196 A.5.4 Index and Subindex ........................................................................................... 196 A.5.5 Data .................................................................................................................. 197 A.5.6 Check ISDU (CHKPDU) ..................................................................................... 197 A.5.7 ISDU examples.................................................................................................. 197 A.6 General structure and encoding of events ................................................................... 199 A.6.1 General ............................................................................................................. 199 A.6.2 StatusCode type 1 (no details) ........................................................................... 200 A.6.3 StatusCode type 2 (with details)......................................................................... 200 A.6.4 EventQualifier.................................................................................................... 201 A.6.5 EventCode ........................................................................................................ 202 Annex B (normative) Parameter and commands ................................................................ 203 B.1 Direct parameter page 1 and 2.................................................................................... 203 B.1.1 Overview ........................................................................................................... 203 B.1.2 MasterCommand ............................................................................................... 204 B.1.3 MasterCycleTime ............................................................................................... 205 B.1.4 MinCycleTime.................................................................................................... 205 B.1.5 F-sequence Capability ....................................................................................... 206 B.1.6 RevisionID (RID) ............................................................................................... 206 B.1.7 ProcessDataIn ................................................................................................... 207 B.1.8 ProcessDataOut ................................................................................................ 208 B.1.9 VendorID (VID) .................................................................................................. 208 B.1.10 DeviceID (DID)....................................................................................... 208 B.1.11 FunctionID (FID) .................................................................................... 208 B.1.12 SystemCommand ................................................................................... 208 B.1.13 Device specific direct parameter page 2 ................................................. 208 B.2 Predefined Device parameters .................................................................................... 208 B.2.1 Overview ........................................................................................................... 208 B.2.2 SystemCommand .............................................................................................. 211 B.2.3 Data Storage Index............................................................................................ 212 B.2.4 Device Access Locks ......................................................................................... 213 B.2.5 Profile Characteristic ......................................................................................... 214 B.2.6 Vendor Name .................................................................................................... 214 B.2.7 Vendor Text....................................................................................................... 215 B.2.8 Product Name ................................................................................................... 215 B.2.9 Product ID ......................................................................................................... 215 B.2.10 Product Text .......................................................................................... 215 B.2.11 SerialNumber ......................................................................................... 215 B.2.12 Hardware Revision ................................................................................. 215 B.2.13 Firmware Revision ................................................................................. 215 B.2.14 Application Specific Tag ......................................................................... 215 B.2.15 Error Count ............................................................................................ 215 B.2.16 Device Status ........................................................................................ 216 B.2.17 Detailed Device Status ........................................................................... 217

61131-9/WD V0.5 IEC

Working Draft

ProcessDataInput .................................................................................. 217 B.2.18 B.2.19 ProcessDataOutput ................................................................................ 217 B.2.20 Offset Time ............................................................................................ 217 B.2.21 Profile Parameter (reserved) .................................................................. 218 B.2.22 Preferred Index ...................................................................................... 218 B.2.23 Extended Index ...................................................................................... 218 B.2.24 Profile specific Index (reserved) ............................................................. 218 Annex C (normative) ErrorTypes (ISDU errors) .................................................................. 219 C.1 General ...................................................................................................................... 219 C.2 Application related ErrorTypes .................................................................................... 219 C.2.1 Overview ........................................................................................................... 219 C.2.2 Device application error no details .................................................................. 220 C.2.3 Index not available ............................................................................................ 220 C.2.4 Subindex not available....................................................................................... 220 C.2.5 Service temporarily not available ....................................................................... 220 C.2.6 Service temporarily not available local control ................................................. 220 C.2.7 Service temporarily not available device control .............................................. 220 C.2.8 Access denied ................................................................................................... 220 C.2.9 Parameter value out of range ............................................................................. 220 C.2.10 Parameter value above limit ................................................................... 221 C.2.11 Parameter value below limit ................................................................... 221 C.2.12 Parameter length overrun ....................................................................... 221 C.2.13 Parameter length underrun ..................................................................... 221 C.2.14 Function not available ............................................................................ 221 C.2.15 Function temporarily unavailable ............................................................ 221 C.2.16 Invalid parameter set ............................................................................. 221 C.2.17 Inconsistent parameter set ..................................................................... 221 C.2.18 Application not ready ............................................................................. 221 C.2.19 Vendor specific ...................................................................................... 221 C.3 Derived ErrorTypes .................................................................................................... 222 C.3.1 Overview ........................................................................................................... 222 C.3.2 Communication error ......................................................................................... 222 C.3.3 Timeout ............................................................................................................. 222 C.3.4 Device event ISDU error ................................................................................. 222 C.3.5 Device event ISDU illegal service primitive ...................................................... 222 C.3.6 Master ISDU checksum error .......................................................................... 222 C.3.7 Master ISDU illegal service primitive ............................................................... 223 C.3.8 Device event ISDU buffer overflow .................................................................. 223 Annex D (normative) EventCodes (diagnosis information) .................................................. 224 D.1 General ...................................................................................................................... 224 D.2 EventCodes for Devices ............................................................................................. 224 Annex E (normative) Data types ........................................................................................ 227 E.1 General ...................................................................................................................... 227 E.2 Basic data types ......................................................................................................... 227 E.2.1 E.2.2 E.2.3 E.2.4 General ............................................................................................................. 227 BooleanT........................................................................................................... 227 UIntegerT .......................................................................................................... 227 IntegerT ............................................................................................................ 228

Working Draft

61131-9/WD V0.5 IEC

E.2.5 Float32T............................................................................................................ 230 E.2.6 StringT .............................................................................................................. 231 E.2.7 OctetStringT ...................................................................................................... 231 E.2.8 TimeT................................................................................................................ 232 E.2.9 TimeSpanT........................................................................................................ 233 E.3 Composite data types ................................................................................................. 234 E.3.1 General ............................................................................................................. 234 E.3.2 ArrayT ............................................................................................................... 234 E.3.3 RecordT ............................................................................................................ 235 Annex F (normative) Structure of the Data Storage data object .......................................... 238 Annex G (normative) Master and Device conformity........................................................... 239 G.1 Conformance classes ................................................................................................. 239 G.1.1 Overview ........................................................................................................... 239 G.1.2 Functional requirements for Devices .................................................................. 239 G.1.3 Functional requirements for Master .................................................................... 239 G.2 Electromagnetic compatibility requirements (EMC) ...................................................... 239 G.2.1 General ............................................................................................................. 239 G.2.2 Operating conditions.......................................................................................... 239 G.2.3 Performance criteria .......................................................................................... 239 G.2.4 Required immunity tests .................................................................................... 240 G.2.5 Required emission tests..................................................................................... 241 G.2.6 Test configurations for Master............................................................................ 241 G.2.7 Test configurations for Devices .......................................................................... 243 G.3 Test strategies for conformity...................................................................................... 244 G.3.1 General ............................................................................................................. 244 G.3.2 Test of a Device ................................................................................................ 244 G.3.3 Test of a Master ................................................................................................ 244 G.4 Manufacturer declaration ............................................................................................ 245 Annex H (informative) Residual error probabilities ............................................................. 246 H.1 Residual error probability of the SDCI data integrity mechanism .................................. 246 H.2 Derivation of EMC test conditions ............................................................................... 246 Annex I (informative) Example sequence of an ISDU transmission ..................................... 248 Annex J (informative) Recommended methods for detecting parameter changes ................ 250 J.1 CRC signature ............................................................................................................ 250 J.2 Revision counter......................................................................................................... 250 Annex K (informative) Information on conformity testing of SDCI........................................ 251 Bibliography ..................................................................................................................... 252

Table 1 Service assignments of Master and Device ..........................................................36 Table 2 PL_Mode.............................................................................................................36 Table 3 PL_Transfer ........................................................................................................36 Table 4 Electric characteristics of a receiver .....................................................................39 Table 5 Electric characteristics of a Master port................................................................39 Table 6 Electric characteristics of a Device.......................................................................40 Table 7 Dynamic characteristics of the transmission .........................................................43

61131-9/WD V0.5 IEC

Working Draft

Table 8 Wake-up request characteristics ..........................................................................44 Table 9 Power-on timing ..................................................................................................45 Table 10 Pin assignments ................................................................................................46 Table 11 Cable characteristics .........................................................................................47 Table 12 Cable conductor assignments ............................................................................48 Table 13 Service assignments within Master and Device...................................................50 Table 14 DL_ReadParam .................................................................................................50 Table 15 DL_WriteParam .................................................................................................51 Table 16 DL_Read ...........................................................................................................52 Table 17 DL_Write ...........................................................................................................53 Table 18 DL_ISDUTransport ............................................................................................53 Table 19 DL_PDOutputUpdate .........................................................................................54 Table 20 DL_PDOutputTransport......................................................................................55 Table 21 DL_PDInputUpdate ............................................................................................56 Table 22 DL_PDInputTransport ........................................................................................56 Table 23 DL_SetMode .....................................................................................................57 Table 24 DL_Mode...........................................................................................................58 Table 25 DL_Event ..........................................................................................................58 Table 26 DL_Control ........................................................................................................59 Table 27 DL-A services within Master and Device .............................................................60 Table 28 CMD..................................................................................................................60 Table 29 PD ....................................................................................................................61 Table 30 PDValid .............................................................................................................63 Table 31 FHInfo ...............................................................................................................63 Table 32 ComTrig ............................................................................................................63 Table 33 PDTrig...............................................................................................................64 Table 34 Wake-up procedure and retry characteristics ......................................................66 Table 35 Fallback timing characteristics ...........................................................................67 Table 36 State transition tables of the Master DL-mode handler ........................................69 Table 37 State transition tables of the Device DL-mode handler ........................................71 Table 38 State transition table of the Master frame handler...............................................75 Table 39 State transition tables of the Device frame handler .............................................77 Table 40 State transition tables of the Master process data handler ..................................79 Table 41 State transition tables of the Device process data handler ..................................80 Table 42 State transition tables of the Master on-request data handler..............................82 Table 43 State transition tables of the Device on-request data handler..............................83 Table 44 FlowCTRL definitions.........................................................................................84 Table 45 State transition tables of the Master service handler ...........................................85 Table 46 State transition tables of the Device service handler ...........................................86 Table 47 Control codes ....................................................................................................87 Table 48 State transition tables of the Master command handler .......................................88 Table 49 State transition tables of the Device command handler .......................................89 Table 50 Event buffer.......................................................................................................89

Working Draft

61131-9/WD V0.5 IEC

Table 51 State transition tables of the Master event handler .............................................90 Table 52 State transition tables of the Device event handler .............................................91 Table 53 AL services within Master and Device ................................................................93 Table 54 AL_Read ...........................................................................................................94 Table 55 AL_Write ...........................................................................................................95 Table 56 AL_Abort ...........................................................................................................96 Table 57 AL_GetInput ......................................................................................................97 Table 58 AL_NewInput .....................................................................................................97 Table 59 AL_SetInput ......................................................................................................98 Table 60 AL_PDCycle ......................................................................................................98 Table 61 AL_GetOutput ...................................................................................................99 Table 62 AL_SetOutput .................................................................................................. 100 Table 63 AL_Event ........................................................................................................ 100 Table 64 AL_Control ...................................................................................................... 102 Table 65 States and transitions for the OD state machine of the Master AL ..................... 103 Table 66 States and transitions for the OD state machine of the Device AL ..................... 105 Table 67 State and transitions of the Event state machine of the Master AL .................... 108 Table 68 State and transitions of the Event state machine of the Device AL .................... 109 Table 69 SM services within the Master.......................................................................... 114 Table 70 SM_SetPortConfig ........................................................................................... 114 Table 71 Definition of the InspectionLevel (IL) ................................................................ 115 Table 72 Definitions of the Target Modes ....................................................................... 115 Table 73 SM_GetPortConfig........................................................................................... 116 Table 74 SM_PortMode.................................................................................................. 117 Table 75 Definition of the port error modes ..................................................................... 117 Table 76 SM_Operate .................................................................................................... 118 Table 77 State transition tables of the Master system management................................. 119 Table 78 State transition tables of the Master submachine CheckCompatibility_1 ............ 121 Table 79 State transition tables of the Master submachine CheckSerNum_3 ................... 124 Table 80 SM services within the Device.......................................................................... 128 Table 81 SM_SetDeviceCom .......................................................................................... 128 Table 82 SM_GetDeviceCom ......................................................................................... 129 Table 83 SM_SetDeviceIdent ......................................................................................... 130 Table 84 SM_GetDeviceIdent ......................................................................................... 131 Table 85 SM_SetDeviceMode ........................................................................................ 132 Table 86 SM_DeviceMode.............................................................................................. 132 Table 87 State transition tables of the Device system management................................. 133 Table 88 State transition tables of the PM state machine ................................................ 141 Table 89 Definitions of parameter checks ....................................................................... 143 Table 90 State transition table of the Data Storage state machine ................................... 147 Table 91 Overview of the protocol constants for Devices ................................................ 153 Table 92 Classification of Device diagnosis incidents...................................................... 154 Table 93 Timing for LED indicators................................................................................. 155

61131-9/WD V0.5 IEC

Working Draft

Table 94 Internal variables and events to control the common Master applications .......... 158 Table 95 State transition tables of the Configuration Manager......................................... 163 Table 96 States and transitions of the Data Storage state machines................................ 168 Table 97 State transition table of the ODE state machine................................................ 171 Table 98 State transitions of the state machine "DIwithSDCI".......................................... 180 Table A.1 Values of communication channel ................................................................... 182 Table A.2 Values of R/W ................................................................................................ 182 Table A.3 Values of F-sequence types ........................................................................... 183 Table A.4 Data types for user data ................................................................................. 183 Table A.5 Values of PD invalid ....................................................................................... 184 Table A.6 Values of the event flag .................................................................................. 184 Table A.7 F-sequence types for the STARTUP mode ...................................................... 190 Table A.8 F-sequence types for the PREOPERATE mode ............................................... 190 Table A.9 F-sequence types for the OPERATE mode (V1.0) ........................................... 191 Table A.10 F-sequence types for the OPERATE mode .................................................... 191 Table A.11 Recommended MinCycleTimes ..................................................................... 193 Table A.12 Definition of the nibble "Service" ................................................................... 195 Table A.13 ISDU syntax ................................................................................................. 196 Table A.14 Definition of nibble Length and octet ExtLength ............................................. 196 Table A.15 Use of Index formats .................................................................................... 197 Table A.16 Mapping of EventCodes (type 1) ................................................................... 200 Table A.17 Values of INSTANCE.................................................................................... 201 Table A.18 Values of SOURCE ...................................................................................... 202 Table A.19 Values of TYPE ............................................................................................ 202 Table A.20 Values of MODE........................................................................................... 202 Table B.1 Direct parameter page 1 and 2 ....................................................................... 204 Table B.2 Types of MasterCommands ............................................................................ 205 Table B.3 Possible values of MinCycleTime.................................................................... 206 Table B.4 Values of ISDU .............................................................................................. 206 Table B.5 Values of SIO................................................................................................. 207 Table B.6 Permitted combinations of BYTE and Length................................................... 207 Table B.7 Index assignment of data objects (Device parameter)...................................... 209 Table B.8 Coding of SystemCommand (ISDU) ................................................................ 211 Table B.9 Data Storage Index assignments .................................................................... 212 Table B.10 Structure of Index_List.................................................................................. 213 Table B.11 Device locking possibilities ........................................................................... 214 Table B.12 Device status parameter ............................................................................... 216 Table B.13 Detailed Device Status (Index 0x0025).......................................................... 217 Table B.14 Time base coding and values of Offset Time ................................................. 218 Table C.1 ErrorTypes ..................................................................................................... 219 Table C.2 Derived ErrorTypes ........................................................................................ 222 Table D.1 EventCodes ................................................................................................... 224 Table D.2 Exemplary SDCI specific EventCodes............................................................. 225

Working Draft

10

61131-9/WD V0.5 IEC

Table E.1 BooleanT ....................................................................................................... 227 Table E.2 BooleanT coding ............................................................................................ 227 Table E.3 UIntegerT....................................................................................................... 228 Table E.4 IntegerT ......................................................................................................... 228 Table E.5 IntegerT coding (8 octets)............................................................................... 229 Table E.6 IntegerT coding (4 octets)............................................................................... 229 Table E.7 IntegerT coding (2 octets)............................................................................... 229 Table E.8 IntegerT coding (1 octet) ................................................................................ 229 Table E.9 Float32T ........................................................................................................ 230 Table E.10 Coding of Float32T ....................................................................................... 230 Table E.11 StringT ......................................................................................................... 231 Table E.12 OctetStringT................................................................................................. 232 Table E.13 TimeT .......................................................................................................... 232 Table E.14 Coding of TimeT ........................................................................................... 233 Table E.15 TimeSpanT .................................................................................................. 233 Table E.16 Coding of TimeSpanT ................................................................................... 233 Table E.17 Example for the access of an ArrayT............................................................. 234 Table E.18 Example 1 for the access of a RecordT ......................................................... 235 Table E.19 Example 2 for the access of a RecordT ......................................................... 235 Table E.20 Example 3 for the access of a RecordT ......................................................... 236 Table F.1 Structure of the stored DS data object............................................................. 238 Table F.2 Associated header information for stored DS data objects ............................... 238 Table G.1 EMC test conditions for SDCI ......................................................................... 240 Table G.2 EMC test levels.............................................................................................. 240 Table J.1 Proper CRC generator polynomials ................................................................. 250

Figure 1 Memory and transmission octet order..................................................................28 Figure 2 SDCI compatibility with IEC 61131-2 ...................................................................29 Figure 3 Domain of the SDCI technology within the automation hierarchy..........................29 Figure 4 Generic Device model for SDCI (Master's view) ..................................................30 Figure 5 Relationship between nature of data and transmission types ...............................31 Figure 6 Object transfer at the application layer level (AL) ................................................32 Figure 7 Logical structure of Master and Device ...............................................................33 Figure 8 Three wire connection system PHY-3W...............................................................34 Figure 9 Topology of SDCI ...............................................................................................34 Figure 10 Physical layer (Master) .....................................................................................35 Figure 11 Physical layer (Device) .....................................................................................35 Figure 12 Line driver reference schematics ......................................................................37 Figure 13 Receiver reference schematics .........................................................................37 Figure 14 Master and Device reference schematics for PHY-3W .......................................38 Figure 15 Voltage level definitions ....................................................................................38 Figure 16 Switching thresholds.........................................................................................39

61131-9/WD V0.5 IEC

11

Working Draft

Figure 17 Format of an SDCI UART frame ........................................................................41 Figure 18 Eye diagram for the 'H' and 'L' detection ...........................................................42 Figure 19 Eye diagram for the correct detection of a UART frame .....................................42 Figure 20 Wake-up request ..............................................................................................44 Figure 21 Power-on timing ...............................................................................................45 Figure 22 Pin layout front view .........................................................................................46 Figure 23 Class A and B port definitions ...........................................................................47 Figure 24 Reference schematic for effective line capacitance and loop resistance .............47 Figure 25 Structure and services of the data link layer (Master) ........................................49 Figure 26 Structure and services of the data link layer (Device) ........................................49 Figure 27 State machines of the data link layer.................................................................64 Figure 28 Example of an attempt to establish communication............................................65 Figure 29 Failed attempt to establish communication ........................................................66 Figure 30 Retry strategy to establish communication ........................................................66 Figure 31 Fallback procedure ...........................................................................................67 Figure 32 Master state machine of the DL-mode handler...................................................68 Figure 33 Submachine to establish communication ...........................................................69 Figure 34 Device state machine of the DL-mode handler...................................................71 Figure 35 SDCI F-sequences ...........................................................................................72 Figure 36 Overview of F-sequence types ..........................................................................73 Figure 37 Master state machine of the frame handler........................................................74 Figure 38 Submachine "Response 4" of the frame handler ................................................75 Figure 39 Submachine "Response 11" of the frame handler ..............................................75 Figure 40 Device state machine of the frame handler........................................................77 Figure 41 Interleave mode for the segmented transmission of process data ......................78 Figure 42 Master state machine of the process data handler .............................................79 Figure 43 Device state machine of the process data handler .............................................80 Figure 44 Master state machine of the on-request data handler ........................................81 Figure 45 Device state machine of the on-request data handler ........................................83 Figure 46 Structure of the ISDU .......................................................................................84 Figure 47 Master state machine of the service handler......................................................85 Figure 48 Device state machine of the service handler......................................................86 Figure 49 Master state machine of the command handler..................................................88 Figure 50 Device state machine of the command handler..................................................88 Figure 51 Master state machine of the event handler ........................................................90 Figure 52 Device state machine of the event handler ........................................................91 Figure 53 Structure and services of the application layer (Master).....................................92 Figure 54 Structure and services of the application layer (Device).....................................93 Figure 55 OD state machine of the Master AL................................................................. 103 Figure 56 OD state machine of the Device AL................................................................. 104 Figure 57 Sequence diagram for the transmission of On-request Data............................. 106 Figure 58 Sequence diagram for On-request Data in case of errors................................. 107 Figure 59 Sequence diagram for On-request Data in case of timeout .............................. 107

Working Draft

12

61131-9/WD V0.5 IEC

Figure 60 Event state machine of the Master AL ............................................................. 108 Figure 61 Event state machine of the Device AL ............................................................. 109 Figure 62 Sequence diagram for output Process Data..................................................... 110 Figure 63 Sequence diagram for input Process Data....................................................... 111 Figure 64 Structure and services of the Master system management............................... 112 Figure 65 Sequence chart of the use case "port x setup" ................................................ 113 Figure 66 Main Master state machine of the System Management................................... 119 Figure 67 SM Master submachine CheckCompatibility_1 ................................................ 121 Figure 68 Activity (check revision) for state "CheckVxy" .................................................. 122 Figure 69 Activity (check comp V10) for state "CheckCompV10" ..................................... 123 Figure 70 Activity (check comp) for state "CheckComp" .................................................. 123 Figure 71 Activity (write parameter) in state "RestartDevice" ........................................... 124 Figure 72 SM Master submachine CheckSerNum_3 ........................................................ 124 Figure 73 Activity (check SerialNumber) for state CheckSerNum_3 ................................. 125 Figure 74 Structure and services of the system management (Device) ............................ 126 Figure 75 Sequence chart of the use case "INACTIVE SIO SDCI SIO".................... 127 Figure 76 State machine of the Device system management ........................................... 133 Figure 77 Sequence chart of a regular Device startup ..................................................... 136 Figure 78 Sequence chart of a Device startup in compatibility mode................................ 137 Figure 79 Sequence chart of a Device startup when compatibility fails ............................ 138 Figure 80 Structure and services of a Device .................................................................. 139 Figure 81 The Parameter Manager (PM) state machine .................................................. 141 Figure 82 Positive and negative parameter checking result ............................................. 143 Figure 83 Positive block parameter download with Data Storage request......................... 144 Figure 84 Negative block parameter download................................................................ 145 Figure 85 The Data Storage (DS) state machine ............................................................. 147 Figure 86 Data Storage request message sequence ....................................................... 148 Figure 87 Cycle timing ................................................................................................... 151 Figure 88 Device LED indicator timing ............................................................................ 155 Figure 89 Generic relationship of SDCI technology and fieldbus technology .................... 156 Figure 90 Structure and services of a Master .................................................................. 157 Figure 91 Relationship of the common Master applications ............................................. 158 Figure 92 Sequence diagram of Configuration Manager actions ...................................... 159 Figure 93 Ports in MessageSync mode ........................................................................... 161 Figure 94 State machine of the Configuration Manager ................................................... 163 Figure 95 Main state machine of the Data Storage mechanism........................................ 165 Figure 96 Submachine "UpDownload_2" of the Data Storage mechanism ........................ 166 Figure 97 Data Storage submachine "Upload_7" ............................................................. 167 Figure 98 Data Storage upload sequence diagram .......................................................... 167 Figure 99 Data Storage submachine "Download_10"....................................................... 168 Figure 100 Data Storage download sequence diagram.................................................... 168 Figure 101 State machine of the On-request Data Exchange........................................... 171 Figure 102 System overview of SDCI diagnosis information propagation via Events ........ 173

61131-9/WD V0.5 IEC

13

Working Draft

Figure 103 Event scheduling .......................................................................................... 174 Figure 104 Event scheduling (multi event transport)........................................................ 175 Figure 105 Process Data mapping from ports to the gateway data stream ....................... 176 Figure 106 Propagation of PD_Invalid from Master to Device .......................................... 177 Figure 107 Example 1 of a PDCT display layout ............................................................. 178 Figure 108 Example 2 of a PDCT display layout ............................................................. 178 Figure 109 Virtual port mode "DIwithSDCI" ..................................................................... 180 Figure A.1 F-sequence control ....................................................................................... 182 Figure A.2 Checksum/F-sequence type octet .................................................................. 183 Figure A.3 Checksum/status octet .................................................................................. 184 Figure A.4 Principle of the checksum calculation and compression.................................. 185 Figure A.5 F-sequence TYPE_0 ..................................................................................... 186 Figure A.6 F-sequence TYPE_1_1 ................................................................................. 186 Figure A.7 F-sequence TYPE_1_2 ................................................................................. 187 Figure A.8 F-sequence TYPE_1_V ................................................................................. 187 Figure A.9 F-sequence TYPE_2_1 ................................................................................. 188 Figure A.10 F-sequence TYPE_2_2................................................................................ 188 Figure A.11 F-sequence TYPE_2_3................................................................................ 188 Figure A.12 F-sequence TYPE_2_4................................................................................ 189 Figure A.13 F-sequence TYPE_2_5................................................................................ 189 Figure A.14 F-sequence TYPE_2_6................................................................................ 189 Figure A.15 F-sequence TYPE_2_V ............................................................................... 190 Figure A.16 F-sequence timing....................................................................................... 193 Figure A.17 Service octet ............................................................................................... 195 Figure A.18 Check of ISDU integrity via CHKPDU........................................................... 197 Figure A.19 Examples of request formats for ISDUs........................................................ 198 Figure A.20 Examples of response ISDUs ...................................................................... 198 Figure A.21 Examples of read and write request ISDUs .................................................. 199 Figure A.22 Structure of StatusCode type 1 .................................................................... 200 Figure A.23 Structure of StatusCode type 2 .................................................................... 200 Figure A.24 Indication of activated events ...................................................................... 201 Figure A.25 Structure of the EventQualifier..................................................................... 201 Figure B.1 Classification and mapping of direct parameters ............................................ 203 Figure B.2 MinCycleTime ............................................................................................... 205 Figure B.3 F-sequence Capability................................................................................... 206 Figure B.4 RevisionID .................................................................................................... 207 Figure B.5 ProcessDataIn .............................................................................................. 207 Figure B.6 Index space for ISDU data objects................................................................. 209 Figure B.7 Implementation rules for parameters and commands...................................... 209 Figure B.8 Structure of the Offset Time .......................................................................... 218 Figure E.1 Coding examples of UIntegerT ...................................................................... 228 Figure E.2 Coding examples of IntegerT ......................................................................... 230 Figure E.3 Singular access of StringT............................................................................. 231

Working Draft

14

61131-9/WD V0.5 IEC

Figure E.4 Coding example of OctetStringT .................................................................... 232 Figure E.5 New definition of NetworkTime in IEC 61158-6:2003 ...................................... 232 Figure E.6 Structuring rules for ArrayT ........................................................................... 234 Figure E.7 Example of an ArrayT data structure.............................................................. 234 Figure E.8 Structuring rules for RecordT......................................................................... 235 Figure E.9 Example 2 of a RecordT structure.................................................................. 236 Figure E.10 Example 3 of a RecordT structure................................................................ 236 Figure E.11 Write requests for example 3 ....................................................................... 237 Figure G.1 Test setup for electrostatic discharge (Master) .............................................. 241 Figure G.2 Test setup for RF electromagnetic field (Master)............................................ 242 Figure G.3 Test setup for fast transients (Master) ........................................................... 242 Figure G.4 Test setup for RF common mode (Master) ..................................................... 242 Figure G.5 Test setup for electrostatic discharges (Device)............................................. 243 Figure G.6 Test setup for RF electromagnetic field (Device)............................................ 243 Figure G.7 Test setup for fast transients (Device) ........................................................... 244 Figure G.8 Test setup for RF common mode (Device) ..................................................... 244 Figure G.9 Layout proposal for a manufacturer's declaration ........................................... 245 Figure H.1 Residual error probability for the SDCI data integrity mechanism ................... 246 Figure I.1 Example for ISDU transmissions ..................................................................... 248 Figure I.2 Example for ISDU transmissions (continued)................................................... 249

61131-9/WD V0.5 IEC

15

Working Draft

INTERNATIONAL ELECTROTECHNICAL COMMISSION

____________

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

International Standard IEC 61131-9 to be prepared by a Joint Working Group of subcommittee 65B: Devices & process analysis, and subcommittee 65C: Industrial networks, of IEC technical committee 65: Industrial process measurement, control and automation. The text of this standard is based on the following documents:
NP XX/XX/NP Report on voting XX/XX/RVD

Full information on the voting for the approval of this standard can be found in the report on voting indicated in the above table. This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

Working Draft

16

61131-9/WD V0.5 IEC

The committee has decided that the contents of this publication will remain unchanged until the maintenance result date 1 indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific publication. At this date, the publication will be reconfirmed, withdrawn, replaced by a revised edition, or amended.

The list of all parts of the IEC 61131 series, under the general title Programmable Controllers, can be found on the IEC website. IMPORTANT The 'colour inside' logo on the cover page of this publication indicates that it contains colours which are considered to be useful for the correct understanding of its contents. Users should therefore print this document using a colour printer.

1 The National Committees are requested to note that for this publication the maintenance result date is 20??.

61131-9/WD V0.5 IEC

17

Working Draft

0
0.1

Introduction
General

IEC 61131-9 is part of a series of standards on programmable controllers and the associated peripherals and should be read in conjunction with the other parts of the series. Where a conflict exists between this and other IEC standards (except basic safety standards), the provisions of this standard should be considered to govern in the area of programmable controllers and their associated peripherals. The increased use of micro-controllers embedded in low-cost digital/analog sensors and actuators has provided opportunities for adding diagnosis and configuration data to support increasing application requirements. The driving force for the SDCI (IO-Link 2 )) technology is the need of these low-cost digital/analog sensors and actuators to exchange this diagnosis and configuration data with a controller (PC or PLC) using a low-cost, digital communication technology while maintaining backward compatibility with the current DI/DO signals. In fieldbus concepts, the SDCI technology defines a generic interface for connecting digital/analog sensors and actuators to a master unit, which may be combined with gateway capabilities to become a fieldbus remote I/O node. Any SDCI compliant device can be attached to any available interface port. SDCI compliant devices perform physical to digital conversion in the device, and then communicate the result directly in a standard 24 V I/O digital format, thus removing the need for different DI, DO, AI, AO modules and a variety of cables. Physical topology is point-to-point from each device to the master using 3 wires over distances up to 20 m. The SDCI physical interface is backward compatible with the usual 24 V I/O signalling specified in IEC 61131-2. Transmission rates of 4,8 kbit/s, 38,4 kbit/s and 230,4 kbit/s are supported. The master of the SDCI interface detects, identifies and manages devices plugged into its ports. Tools allow the association of devices with their corresponding electronic I/O device descriptions and their subsequent configuration to match the application requirements. The SDCI technology specifies three different levels of diagnostic capabilities: for immediate response by automated needs during the production phase, for medium response by operator intervention, or for longer term commissioning and maintenance via extended diagnosis information. The structure of this document is described in 4.8. Conformity with IEC 61131-9 cannot be claimed unless the requirements of Annex G are met. Terms of general use are defined in IEC 61131-1 or in [1]. More specific terms are defined in each part.
2 IO-Link T M is a trade name of the "IO-Link Consortium". This information is given for the convenience of users of this international Standard and does not constitute an endorsement by IEC of the trade name holder or any of its TM products. Compliance to this standard does not require use of the registered logos for IO-Link . Use of the TM registered logos for IO-Link requires permission of the "IO-Link Consortium".

Working Draft 0.2 Patent declaration

18

61131-9/WD V0.5 IEC

The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance with this document may involve the use of patents concerning the point-to-point serial communication interface for small sensors and actuators as follows, where the [xx] notation indicates the holder of the patent right: DE 10030845A1 EP 1168271A2 US 6889282B2 DE 100 54 288 A1 [AB] Fieldbus connecting system for actuators or sensors

[FE]

Sensoranordnung zur Erfassung wenigstens eines Messwerts Verfahren und Vorrichtungen zum bertragen von Daten auf einer Datenleitung zwischen einem Steuergert und zumindest einem dezentralen Datenverarbeitungsgert Verfahren und Vorrichtung zur Inbetriebnahme eines Gerts Coupling apparatus for the coupling of devices to a bus system

DE 102005 014783 A1

[SI]

DE 102004 035831 A1

[SI]

DE 102 119 39 A1 US 2003/0200323 A1

[SK]

IEC takes no position concerning the evidence, validity and scope of these patent rights. The holders of these patents rights have assured the IEC that they are willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statements of the holders of these patent rights are registered with IEC. Information may be obtained from: [AB] ABB AG Heidelberg Germany Festo AG Esslingen Germany Siemens AG I IA AS FA TC Karlsruhe Germany Sick AG Waldkirch Germany

[FE]

[SI]

[SK]

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those identified above. IEC shall not be held responsible for identifying any or all such patent rights.

61131-9/WD V0.5 IEC 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

19

Working Draft

PROGRAMMABLE CONTROLLERS Part 9: Single-drop digital communication interface for small sensors and actuators (SDCI)

Scope

The single-drop digital communication interface (SDCI) technology described in this part 9 of the IEC 61131 series focuses on simple sensors and actuators in factory automation, which are nowadays using small and cost-effective microcontrollers. With the help of the SDCI technology, the existing limitations of traditional signal connection technologies such as switching 0/24 V, analog 0 V to 10 V, etc. can be turned into a smooth migration. Classic sensors and actuators are usually connected to a fieldbus system via input/output modules in so-called remote I/O peripherals. The (SDCI) Master function enables these peripherals to map SDCI Devices onto a fieldbus system or build up direct gateways. Thus, parameter data can be transferred from the PLC level down to the sensor/actuator level and diagnosis data transferred back in turn by means of the SDCI communication. This is a contribution to consistent parameter storage and maintenance support within a distributed automation system. SDCI is compatible to classic signal switching technology according to part 2 of the IEC 61131 series. This part describes the SDCI communication, comprising the specifications of the physical layer, the data link layer and the application layer for SDCI Masters and SDCI Devices following the ISO/OSI reference model. Communication interfaces or systems incorporating multiple point or multiple drop linkages are not covered by this standard. This version also includes EMC test requirements, and a template for the manufacturer's conformity declaration.

Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. IEC 60947-5-2, Low-voltage switchgear and controlgear Part 5-2: Control circuit devices and switching elements Proximity switches IEC 61000-4-2, Electromagnetic compatibility (EMC) Part 4-2: Testing and measurement techniques Electrostatic discharge immunity test IEC 61000-4-3, Electromagnetic compatibility (EMC) Part 4-3: Testing and measurement techniques Radiated, radio-frequency, electromagnetic field immunity test IEC 61000-4-4, Electromagnetic compatibility (EMC) Part 4-4: Testing and measurement techniques Electrical fast transient/burst immunity test IEC 61000-4-5, Electromagnetic compatibility (EMC) Part 4-5: Testing and measurement techniques Surge immunity test IEC 61000-4-6, Electromagnetic compatibility (EMC) Part 4-6: Testing and measurement techniques Immunity to conducted disturbances, induced by radio-frequency fields

Working Draft 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

20

61131-9/WD V0.5 IEC

IEC 61000-6-4, Electromagnetic compatibility (EMC) Part 6: Generic standards Section 4: Emission standard for industrial environments IEC 61076-2-101, Connectors for electronic equipment Product requirements Part 2-101: Circular connectors - Detail specification for M12 connectors with screw-locking IEC 61131-2, Programmable controllers Part 2: Equipment requirements and tests IEC 61158-2, Digital data communications for measurement and control Fieldbus for use in industrial control systems Part 2: Physical layer specification and service definition IEC 61158-3, Digital data communications for measurement and control Fieldbus for use in industrial control systems Part 3: Data link layer service definition IEC 61158-4, Digital data communications for measurement and control Fieldbus for use in industrial control systems Part 4: Data link layer protocol specification IEC 61158-5, Digital data communications for measurement and control Fieldbus for use in industrial control systems Part 5: Application layer service definition IEC 61158-6, Digital data communications for measurement and control Fieldbus for use in industrial control systems Part 6: Application layer protocol specification IEC 61784-1, Digital data communications for measurement and control Part 1: Profile sets for continuous and discrete manufacturing relative to fieldbus use in industrial control systems ISO/IEC 10731, Information technology Open Systems Interconnection Basic Reference Model Conventions for the definition of OSI services ISO/IEC 7498-1, Information technology Open Systems Interconnection Basic Reference Model Part 1: The Basic Model

3
3.1

Terms, definitions, symbols, abbreviated terms and conventions

Terms and definitions

For the purposes of this document, the following terms and definitions in addition to those given in IEC 61131-1 and IEC 61131-2 apply. 3.1.1 address part of the F-sequence control to reference data within data categories of a communication channel 3.1.2 application layer (AL) <SDCI> part of the protocol responsible for the transmission of Process Data objects and OnRequest Data objects 3.1.3 block parameter consistent parameter access via multiple Indices or Subindices

61131-9/WD V0.5 IEC 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122

21

Working Draft

3.1.4 checksum <SDCI> complementary part of the overall data integrity measures in the data link layer in addition to the UART parity bit 3.1.5 CHKPDU integrity protection data within an ISDU communication channel generated through XOR processing the octets of a request or response 3.1.6 coded switching SDCI communication, based on the standard binary signal levels of IEC 61131-2 3.1.7 COM1 transmission rate of 4,8 kbit/s 3.1.8 COM2 transmission rate of 38,4 kbit/s 3.1.9 COM3 transmission rate of 230,4 kbit/s 3.1.10 COMx one out of three possible transmission rates COM1, COM2, or COM3 3.1.11 communication error unexpected disturbance of the SDCI transmission protocol 3.1.12 cycle time time to transmit an F-sequence between a Master and its Device including the following idle time 3.1.13 communication channel logical connection between Master and Device
NOTE Four communication channels are defined: process channel, page and ISDU channel (for parameters) and diagnosis channel.

3.1.14 Device single passive peer to a Master such as a sensor or actuator

NOTE Uppercase "Device" is used for SDCI equipment, while lowercase "device" is used in a generic manner.

3.1.15 direct parameters directly (page) addressed parameters transferred acyclically via the page communication channel without acknowledgement

Working Draft 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164

22

61131-9/WD V0.5 IEC

3.1.16 dynamic parameter part of a Device's parameter set defined by on-board user interfaces such as teach-in buttons or control panels in addition to the static parameters 3.1.17 event an instance of a change of conditions
NOTE An event is indicated via the event flag within the Device's status cyclic information, then acyclic transfer of event data (typically diagnosis information) is conveyed through the diagnosis communication channel.

[IEC 61158-5-x, modified] 3.1.18 fallback transition of a port from coded switching to switching signal mode 3.1.19 F-sequence sequence of two messages (frames) comprising a Master message and its subsequent Device message 3.1.20 F-sequence control first octet in a Master message indicating the read/write operation, the type of the communication channel, and the address, for example offset or flow control 3.1.21 F-sequence error unexpected or wrong frame content, or no response 3.1.22 F-sequence type one particular F-sequence format out of a set of specified F-sequence formats 3.1.23 frame denigrated synonym for data-link PDU [IEC 61158-3-x] 3.1.24 framing error perturbed UART frames (physical layer) 3.1.25 interleave segmented cyclic data exchange for process data with more than 2 octets through subsequent cycles 3.1.26 ISDU indexed service data unit used for acyclic acknowledged transmission of parameters that can be segmented in a number of F-sequences

61131-9/WD V0.5 IEC 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210

23

Working Draft

3.1.27 Master active peer connected through ports to one up to n Devices and which provides an interface to the gateway to the upper level communication systems or PLCs
NOTE Uppercase "Master" is used for SDCI equipment, while lowercase "master" is used in a generic manner.

3.1.28 message <SDCI> coherent set of UART frames transferred either from a Master to its Device or vice versa following the rules of the SDCI protocol 3.1.29 on-request data acyclically transmitted data upon request of the Master application consisting of parameters or event data 3.1.30 PHY-3W three wire connection to Devices for power, ground, communication and/or switching signals defined in IEC 60947-5-2 3.1.31 physical layer first layer of the ISO-OSI reference model, which provides the mechanical, electrical, functional and procedural means to activate, maintain, and de-activate physical connections for bit transmission between data-link entities
NOTE Physical layer provides means for wake-up and fallback procedures.

[ISO/IEC 7498-1, modified] 3.1.32 port communication medium interface of the Master to one Device 3.1.33 port operating mode state of a Master's port that can be either INACTIVE, DO, DI, SDCI, or ScanMode 3.1.34 process data input or output values from or to a discrete or continuous automation process cyclically transferred with high priority and in a configured schedule automatically after start-up of a Master 3.1.35 process data cycle complete transfer of all process data from or to an individual Device that may comprise several cycles in case of segmentation (interleave) 3.1.36 single parameter independent parameter access via one single Index or Subindex 3.1.37 SIO port operation mode in accordance with digital input and output defined in IEC 61131-2 that is established after power-up or fallback or unsuccessful communication attempts

Working Draft 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234

24

61131-9/WD V0.5 IEC

3.1.38 static parameter part of a Device's parameter set to be saved in a Master for the case of replacement without engineering tools 3.1.39 switching signal binary signal from or to a Device when in SIO mode (as opposed to the "coded switching" SDCI communication) 3.1.40 system management (SM) <SDCI> means to control and coordinate the internal communication layers and the exceptions within the Master and its ports, and within each Device 3.1.41 UART frame <SDCI> bit sequence starting with a start bit, followed by eight bits to carry a data octet, followed by an even parity bit and ending with one stop bit 3.1.42 wake-up procedure for causing a Device to change its mode from SIO to SDCI 3.1.43 wake-up request (WURQ) physical layer service used by the Master to initiate wake-up of a Device, and put it in a receive ready state 3.2
f DTR PS AL BEP C/Q CL eff CQ DI DL DO f DTR H/L I/O ILL IQ IQH IQL IQPK IQPKH IQPKL

Symbols and abbreviated terms

Permissible deviation from data transfer rate, measured in % Power supply ripple, measured in V Application Layer Bit error probability Connection for communication (C) or switching (Q) signal (SIO) Effective total cable capacity, measured in nF Input capacity at C/Q connection, measured in nF Digital input Data Link Layer Digital output Data transfer rate, measured in bit/s High/low signal at receiver output Input / output Input load current at input C/Q to V0, measured in A Driver current in saturated operating status ON, measured in A Driver current on high-side driver in saturated operating status ON, measured in A Driver current on low-side driver in saturated operating status ON, measured in A Maximum driver current in unsaturated operating status ON, measured in A Maximum driver current on high-side driver in unsaturated operating status ON, measured in A Maximum driver current on low-side driver in unsaturated operating status ON,

61131-9/WD V0.5 IEC

measured in A IQQ IQ WU IS ISIR LED LL+ n WU On/Off ON-REQ OVD PDCT PL PLC PS r RL eff s SDCI SIO SM t1 t2 tA T BIT t CYC t DF T DMT t DR T DSIO T DWU t F-sequence t idle tH tL t ND T OFS T RDL T REN

25

Working Draft

Quiescent current at input C/Q to V0 with inactive output drivers, measured in A Amplitude of Masters wake-up request current, measured in A Supply current at V+, measured in A Current pulse supply capability at V+, measured in A Light emitting diode Ground connection Power supply connection Wake-up retry count Drivers ON/OFF switching signal On-request data Signal Overload Detect Port and Device configuration tool Physical layer Programmable logic controller Power supply, measured in V Time to reach a stable level with reference to the beginning of the start bit, measured in T BIT Loop resistance of cable, measured in Time to exit a stable level with reference to the beginning of the start bit, measured in T BIT Single-drop digital communication interface Standard Input Output (digital switching mode) System Management Character transfer delay on Master, measured in T BIT Character transfer delay on Device, measured in T BIT Response delay on Device, measured in T BIT Bit time, measured in s Cycle time on F-sequence level, measured in s Fall time, measured in s Delay time while establishing Master port communication, measured in T BIT Rise time, measured in s Delay time on Device for transition to SIO mode following wake-up request, measured in s Wake-up retry delay, measured in s F-sequence duration, measured in T BIT Idle time between two F-sequences, measured in s Detection time for high level, measured in s Detection time for low level, measured in s Noise suppression time, measured in s Temporal offset for process data processing on the Device with reference to start of cycle, measured in s Wake-up readiness following power ON, measured in s Receive enable, measured in s [IEC 61131-2]

Working Draft
T SD T WU UART UML V+ V0 VDVD+ VDQ VHYS VI VIH VIL VRQ VRQH VRQL VTH VTHH VTHL WURQ Device detect time, measured in s

26

61131-9/WD V0.5 IEC

Pulse duration of wake-up request, measured in s Universal asynchronous receiver transmitter Unified modelling language Voltage at L+ Voltage at LVoltage drop on the line between the L- connections on Master and Device, measured in V Voltage drop on the line between the L+ connections on Master and Device, measured in V Voltage drop on the line between the C/Q connections on Master and Device, measured in V Hysteresis of receiver threshold voltage, measured in V Input voltage at connection C/Q with reference to V0, measured in V Input voltage range at connection C/Q for high signal, measured in V Input voltage range at connection C/Q for low signal, measured in V Residual voltage on driver in saturated operating status ON, measured in V Residual voltage on high-side driver in operating status ON, measured in V Residual voltage on low-side driver in saturated operating status ON, measured in V Threshold voltage of receiver with reference to V0, measured in V Threshold voltage of receiver for safe detection of a high signal, measured in V Threshold voltage of receiver for safe detection of a low signal, measured in V Wake-up request pulse

235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 3.3 3.3.1 Conventions General

The service model, service primitives, and the diagrams shown in this document are entirely abstract descriptions. They do not represent a complete specification for implementation. 3.3.2 Service parameters

Service primitives are used to represent service provider/consumer interactions (ISO/IEC 10731). They convey parameters which indicate the information available in the provider/ consumer interaction. In any particular interface, not each and every parameter needs to be explicitly stated. The service specification in this document uses a tabular format to describe the component parameters of the service primitives. The parameters which apply to each group of service primitives are set out in tables. Each table consists of up to five columns for the 1) parameter name, 2) request primitive (.req), 3) indication primitive (.ind), 4) response primitive (.rsp), and 5) confirmation primitive (.cnf).

61131-9/WD V0.5 IEC 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284

27

Working Draft

One parameter (or component of it) is listed in each row of each table. Under the appropriate service primitive columns, a code is used to specify the type of usage of the parameter on the primitive specified in the column. M Parameter is mandatory for the primitive. U Parameter is a user option, and can or cannot be provided depending on dynamic usage of the service user. When not provided, a default value for the parameter is assumed. C Parameter is conditional upon other parameters or upon the environment of the service user. S Parameter is never present. Parameter is a selected item.

Some entries are further qualified by items in brackets. These may be a) a parameter-specific constraint "(=)" indicates that the parameter is semantically equivalent to the parameter in the service primitive to its immediate left in the table; b) an indication that some note applies to the entry "(n)" indicates that the following note "n" contains additional information related to the parameter and its use. 3.3.3 Service procedures

The procedures are defined in terms of the interactions between application entities through the exchange of protocol data units, and the interactions between a communication layer service provider and a communication layer service consumer in the same system through the invocation of service primitives.

These procedures are applicable to instances of communication between systems which support time-constrained communications services within the communication layers. 3.3.4 Service attributes

The nature of the different (Master and Device) services is characterized by attributes. All services are defined from the view of the affected layer towards the layer above. I Initiator of a service (towards the layer above)

R Receiver (responder) of a service (from the layer above) 3.3.5 Memory and transmission octet order

Figure 1 demonstrates the order that shall be used when transferring WORD based data types from memory to transmission and vice versa (7.3.3.2).

Working Draft
Memory n+4 n+3 n+2 n+1 n
LSO MSO

28

61131-9/WD V0.5 IEC

Transmission
215

MSO

LSO 20

285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 3.3.6

Transmission time

Figure 1 Memory and transmission octet order Behavioral descriptions

For the behavioral descriptions, the notations of UML 2 [5] are used, mainly state, sequence, activity, and timing diagrams. The layout of the associated state-transition tables is following IEC 62390 [4]. Due to design tool restrictions the following exceptions apply. For state diagrams, a service parameter (in capital letters) is attached to the service name via an underscore character, such as for example in DL_SetMode_INACTIVE. For sequence diagrams, the service primitive is attached via an underscore character instead of a dot, and the service parameter is added in parenthesis, such as for example in DL_Event_ind (OPERATE). Timing constraints are labelled "tm(time in ms)". Asynchronously received service calls are not modelled in detail within state diagrams.

4
4.1

Overview of SDCI (IO-Link TM 3 )

Purpose of technology

The single-drop digital communication interface technology for small sensors and actuators SDCI (commonly known as IO-Link TM ) defines a migration path from the existing digital input and digital output interfaces for switching 24 V Devices as defined in IEC 61131-2 towards a point-to-point communication link. Thus, for example, digital I/O modules in existing fieldbus peripherals can be replaced by SDCI Master modules providing both classic DI/DO interfaces and SDCI. Analog transmission technology can be replaced by SDCI combining its robustness, parameterization, and diagnostic features with the saving of digital/analog and analog/digital conversion efforts. Figure 2 shows the basic concept of SDCI.

3 IO-Link T M is a trade name of the "IO-Link Consortium". This information is given for the convenience of users of this international Standard and does not constitute an endorsement by IEC of the trade name holder or any of its TM products. Compliance to this standard does not require use of the registered logos for IO-Link . Use of the TM registered logos for IO-Link requires permission of the "IO-Link Consortium".

61131-9/WD V0.5 IEC

29
Pin 1 Signal L+ I/Q LQ C Definition 24 V Not connected, DI, or DO 0V "Switching signal" DI, DO (SIO) "Coded switching" (SDCI)

Working Draft
Standard IEC 61131-2 IEC 61131-2 IEC 61131-2 IEC 61131-2 IEC 61131-9

L+ SIO

1 2 3 4

C/Q

2 3

SDCI

4,8 / 38,4 / 230,4 kbit/s

L-

308 309 310 311 4.2

IEC 60947-5-2

Figure 2 SDCI compatibility with IEC 61131-2 Positioning within the automation hierarchy

Figure 3 shows the domain of the SDCI technology within the automation hierarchy.
PLC // Host PLC Host Fieldbus controller Fieldbus controller Fieldbus integration

Parameter server

Fieldbus interface Fieldbus interface Gateway application Gateway application Master Master SDCI Port 1 Port 2 Port n Data storage

Engineering: configuration, parameterization, diagnosis, identification & maintenance

Device Device Application Application

Device Device Application Application

Device Device Application Application

312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328

Device description

Figure 3 Domain of the SDCI technology within the automation hierarchy The SDCI technology defines a generic interface for connecting digital/analog sensors and actuators to a master unit, which may be combined with gateway capabilities to become a fieldbus remote I/O node. Starting point for the design of SDCI is the classic 24 V digital input and output interface (DI/DO) defined in IEC 61131-2. Thus, SDCI offers connectivity of classic 24 V sensors ("switching signals") as a default operational mode and connectivity of actuators after configuration to a port ("single-drop"). Many sensors and actuators nowadays are already equipped with microcontrollers offering a UART interface that easily can be complemented to an SDCI with the help of a few hardware components and protocol software. This leads to a second operational mode, communication via "coded switching". After a corresponding start-up, SDCI allows for parameterization, cyclic data exchange, diagnosis reporting, external parameter storage for fast replacement, and identification & maintenance information. Sensors and actuators with these capabilities are simply called "Devices" in this document. For start-up performance reasons these Devices usually provide non-volatile parameter storage.

Working Draft 329 330 331 332 333 334 335 336 337 338 339

30

61131-9/WD V0.5 IEC

Configuration and parameterization of Devices is supported through an XML-based device description [3], which is not part of this document. 4.3 Wiring, connectors and power

The default connection (port class A) wiring complies with IEC 60947-5-2 using three wires for 24 V, 0 V, and a signal line. Four wire connections are specified using an additional wire on a port class A to interface with a separate digital input or, after appropriate configuration, a digital output. Five wire connections (port class B) are specified for Devices requiring additional power from an independant 24 V power supply. Maximum length of cables is 20 m, shielding is not required. 4.4 Communication features of SDCI

The generic Device model is shown in Figure 4 and explained in the following section.
Process data Parameter and commands
232 0xFFFF Index 0...65535, 232 octets/index maximum 0

0...32 octets in

0xFF

Event buffer (diagnosis)

Subindex 1...255 selective Subindex 0 entire record ... ... 0x00 15 0 232 Direct parameter page 1+2 0

0...32 octets out

0...32 octets

0x00

340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357

Figure 4 Generic Device model for SDCI (Master's view) A Device may receive process data (out) to control a discrete or continuous automation process or send process data (in) representing its current state or measurement values. The Device usually provides parameters enabling the user to adjust its functions to particular needs. In this case a large parameter space is defined in principle via an Index (0 to 65 535; see B.2.1 for constraints) and a Subindex (0 to 255) thus allowing easy access without administrative overhead. The space in Index 0 and 1 is reserved for the direct parameter page 1 and 2 with a maximum of 16 octets each. Parameter page 1 is mainly dedicated to Master commands for the Device to start, to fallback, etc., and Device specific operational and identification information. Parameter page 2 allows for a maximum of 16 Device specific socalled anonymous parameters (Table 91). The other indices >1 allow for 232 octets. A Subindex 0 indicates transmission of the complete content addressed by the Index, whereas the other subindices allow for selective access to data items within a record. Any change of device condition requiring reporting or intervention are stored within an event buffer before transmission. An event flag in the cyclic data exchange indicates the existence of an event.

61131-9/WD V0.5 IEC 358 359 360 361 362 363 364 365

31

Working Draft

Communication between a Master and a Device is point-to-point and is based on the principle of a Master first sending a request message and then a Device sending a response message ( Figure 35). Both messages together are called an F-sequence. For all kinds of user data transmission several F-sequence types are defined to choose from (Figure 36). User data such as process data (in, out), parameter data (read/write objects), and events with diagnosis data are identified as data categories and transmitted through communication channels within the data link layer (Figure 5). The diagnosis data is subdivided into the 3 severity levels error, warning, and notification.
Nature of Data Data Categories
Input, Output Input, Output Operation Operation Valid, Invalid Valid, Invalid Direct parameter page Direct parameter page (Page 1 or 2) (Page 1 or 2) Process Process Cyclic (default) Cyclic (default)

Communication Channel

Transmission Type

Page Page

Configuration/ Configuration/ maintenance maintenance

Parameter Parameter (Index >1) (Index >1)

ISDU ISDU On-request (acyclic) On-request (acyclic)

Errors Errors Events Events Warnings Warnings Notifications Notifications Diagnosis Diagnosis

366 367 368 369 370 371 372 373 374 375 376 377 378

Figure 5 Relationship between nature of data and transmission types The first octet of a Master message controls the data transfer direction (read/write) and the type of communication channel. Figure 6 shows how the data link layer is associated with each port of a Master. On the application layer level, the particular services of the data link layer are translated into the process data objects, the read/write of on-request data objects, and the event handling. Master applications accommodate a Configuration Manager (CM), Data Storage mechanism (DS), Diagnosis Unit (DU), On-request Data Exchange (ODE), and a Process Data Exchange (PDE). System management adjusts the ports according to the chosen configuration while considering the properties of the connected Devices. It controls the state machines in the application (AL) and data link layers (DL), for example at start-up.

Working Draft

32

61131-9/WD V0.5 IEC

Master applications
System management System management

Read

Write

On-request data objects DL DL Port Port ...

Event n ... Event n+4 Event n+5 DL DL Port Port ...

Input Output Process data objects DL DL Port Port

Application layer (AL)

Data link layer (DL) Physical layer (PL)

Acyclic communication channels (on-request)

Cyclic communication channel (process data)

System management System management

DL DL On-request data objects Read Write Event n ... Event n+4 Event n+5 Process data objects Input Output

379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 4.5

Device technology Device technology

Figure 6 Object transfer at the application layer level (AL) Role of a Master

A Master accommodates 1 to n ports and the associated data link layers. During start-up it changes the ports to the user-selected port modes, which can be INACTIVE, DI, DO, SDCI, and ScanMode. In case of SDCI mode, a special wake-up current pulse initiates communication with the Device while auto-adjusting the transmission rate to COM1, COM2, or COM3 (Table 7) and checks the "personality" of the connected Device, i.e. its Vendor-ID, Device-ID, and communication properties. If there is a mismatch between the Device parameters and the stored parameter set within the Master, the parameters in the Device are overwritten (11.3) or the stored parameters within the master are updated depending on configuration. It is also possible to start with SDCI communication and after parameterization intentionally switch to DI mode via a fallback command (11.8.5). Coordination of the ports is also a task of the Master which the user can configure through the selection of port cycle modes. In FreeRunning mode, each port defines its own cycle based on the properties of the connected Device. In MessageSync mode, messages (frames) sent on the connected ports start at the same time or in a defined staggered manner. In FixedValue mode, each port uses a user-defined fixed cycle time (11.2.2.2). The Master is responsible for the assembling and disassembling of all data from or to the Devices (see Clause 11). The Master provides a data storage of at least 2 048 octets for each Device connected to a port for Device backup (see 11.3). The Master combines this Device data together with all other relevant data for its own operation, and builds-up bulk data to make it available for higher level applications for Master backup purpose or recipe control (see 11.8.3).

61131-9/WD V0.5 IEC 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 4.6 Engineering for SDCI

33

Working Draft

Engineering for a Master is usually provided by a port and Device configuration tool (PDCT). The PDCT is not only dealing with port properties but also with the Device properties as shown in Figure 4. It combines both an interpreter of the XML-based device description (IODD) and a configurator (11.7). The IODD provides all the necessary properties to establish communication and the necessary parameters and their boundaries to establish the desired function of a sensor or actuator. The PDCT also supports the compilation of the process data for propagation on the fieldbus and vice versa. 4.7 Mapping to fieldbuses

Integration of a Master, i.e. the mapping of the Process Data exchange, the realization of program-controlled parameterization or a remote parameter server and the propagation of diagnosis information to a particular fieldbus is not within the responsibility of this document. The integration of a PDCT into engineering tools of a particular fieldbus is not within the responsibility of this document. 4.8 Document structure

Figure 7 shows the logical structure of the Master and Device. Clause 5 specifies the Physical Layer (PL) of SDCI, Clause 6 specifies details of the SIO mode. Clause 7 specifies Data Link Layer (DL) services, protocol, wake-up, F-sequences, and the DL layer handlers. Clause 8 specifies the services and the protocol of the Application Layer (AL) and Clause 9 the System Management responsibilities (SM).
Master CM DS ODE AL SM DL PL DL PL DL PL ... ... SIO SM DU PDE PM DS AL DL PL SIO Device ED PDE

424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444

Medium

Figure 7 Logical structure of Master and Device Clause 10 concerns the different Process Data (PDE) the Device is exchanging with the Master, the Parameter Management (PM) and Data Storage (DS) aspects and the diagnosis propagation to the Master via an Event Dispatcher (ED). Technology specific applications are not part of this document. They may be described in profiles for particular Device families. Clause 11 covers the Master applications Process Data Exchange (PDE), On-request Data Exchange (ODE), Configuration Management (CM), and Data Storage (DS) for parameters of connected Devices. A Diagnosis Unit (DU) takes care of the processing and propagation of Events (diagnosis information) to other Master applications, or into a fieldbus or other higher level system the Master is embedded in. Several normative and informative annexes are included. Annex A defines the available Fsequence types. Annex B describes the parameters of the direct parameter page and the fixed Device parameters. Annex C lists the error types in case of acyclic transmissions and Annex D the Event codes (diagnosis information of Devices). Annex E specifies the available basic and composite data types. Annex F defines the structure of data storage objects. Annex G deals with conformity and electromagnetic compatibility test requirements and Annex H provides graphs of residual error probabilities, demonstrating the level of SDCI's data integrity. The informative Annex I provides an example of the sequence of acyclic data transmissions. The informative Annex J explains two recommended methods for detecting parameter changes in the context of Data Storage.

Working Draft 445 446 447 448 449 450 451 452 453

34

61131-9/WD V0.5 IEC

Annex K provides contact details for organizations, which support the SDCI technology and offer help with design, conformity testing, device description and fieldbus integration.

5
5.1

Physical Layer (PL)

General Basics

5.1.1

The 3-wire connection system of SDCI (called PHY-3W) is based on the specifications in IEC 60947-5-2. The three lines are used as follows: (L+) for the 24 V power supply, (L-) for the ground line, and (C/Q) for the switching signal (Q) or SDCI communication (C), as shown in Figure 8.
L+ C/Q L-

Master

Device

454 455 456 457 458 459 460 461 462 463 464 465 466 467 Figure 8 Three wire connection system PHY-3W
NOTE Binary sensors compliant with IEC 60947-5-2 are compatible with the PHY-3W interface (including from a power consumption point of view).

Support of PHY-3W is mandatory for Master. Ports with this characteristic are called port class A. Four wire connections are specified using an additional wire on a port class A to interface with a separate digital input or, after appropriate configuration, a digital output (10.10). Five wire connections (port class B) are specified for Devices requiring additional power from an independant 24 V power supply (see 5.5.1). 5.1.2 Topology

The SDCI system topology uses point-to-point links between a Master and its Devices as shown in Figure 9. The Master may have multiple ports for the connection of Devices. Only one Device shall be connected to each port.
Master Ports 1 2 3 ... n

SDCI links

468 469 470 471 472 5.2 5.2.1

Devices

Figure 9 Topology of SDCI Physical layer services Overview

Figure 10 presents an overview of the Master's physical layer and its services.

61131-9/WD V0.5 IEC

System Management
Port x handler Master DL-mode handler

35
Data Link Layer
Frame handler

Working Draft

DI / DO

PL-Mode.req

PL-WakeUp.req

PL-Transfer.req

PL-Transfer.ind

Mode switch Inactive Wake-up Physical Layer (port) Coded switching Switching signal

473 474 475 476 477 478 479 480 481 482 483 484 485

Figure 10 Physical layer (Master) The physical layer specifies the operation of the C/Q line in Figure 2 and the associated line driver (transmitter) and receiver of a particular port. The Master operates this line in three different modes (see Figure 10): inactive, SDCI ("Coded switching"), and SIO ("Switching signal"). The service PL-Mode.req is responsible for switching into one of these modes. If the port is in inactive mode, the C/Q line shall be high impedance (floating). In SIO mode, the port can be used as a standard input or output interface according to the definitions of IEC 61131-2. The communication layers of SDCI are bypassed as shown in Figure 10; the signals are directly processed within the Master application. In SDCI mode, the service PL_WakeUp.req creates a special signal pattern (current pulse) that can be detected by an SDCI enabled Device connected to this port (5.3.3.3). Figure 11 presents an overview of the Device's physical layer and its services.
System Management
Line handler Device DL-mode handler

Data Link Layer

Frame handler

DI / DO

PL-Mode.req

PL-WakeUp.ind

PL-Transfer.ind

PL-Transfer.req

Mode switch Wake-up Coded switching Switching signal

486 487 488 489 490 491 492 493 494 495 496 497 498 499 500

Physical Layer

Figure 11 Physical layer (Device) The physical layer of a Device according to Figure 11 follows the same principle, except that there is no inactive state. By default at power on or cable reconnection, the Device shall operate in the SIO mode, as a digital input. The Device shall always be able to detect a wakeup current pulse (wake-up request). The service PL_WakeUp.ind reports successful detection of the wake-up request (usually a microcontroller interrupt), which is required for the Device to switch to the SDCI mode. A special MasterCommand (fallback) sent via SDCI causes the Device to switch back to SIO mode. Subsequently, the services are defined that are provided by the PL to System Management and to the Data Link Layer (see Figure 80 and Figure 90 for a complete overview of all the services). Table 1 lists the assignments of Master and Device to their roles as initiator or receiver for the individual PL services.

Working Draft 501

36

61131-9/WD V0.5 IEC

Table 1 Service assignments of Master and Device

Service name PL-Mode PL-WakeUp PL-Transfer Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service Master R R I/R Device R I R/I

502 503 504 505 506 507 5.2.2 5.2.2.1 PL services PL_Mode

The PL-Mode service is used to setup the electrical characteristics and configurations of the Physical Layer. The parameters of the service primitives are listed in Table 2. Table 2 PL_Mode
Parameter name Argument TargetMode M M .req

508 509 510 511 512 513 514 515 516 517 518 519 520 521

Argument The service specific parameters of the service request are transmitted in the argument. TargetMode This parameter specifies the requested operation mode Permitted values : INACTIVE, DI, DO, COM1, COM2, COM3

5.2.2.2

PL_WakeUp

The PL-WakeUp service initates or indicates a specific sequence which prepares the Physical Layer to send and receive communication requests (5.3.3.3). This service has no parameters. 5.2.2.3 PL_Transfer

The PL-Transfer service is used to exchange the SDCI data between Data Link Layer and Physical Layer. The parameters of the service primitives are listed in Table 3. Table 3 PL_Transfer
Parameter name Argument Data Status M M M .req ind.

522 523 524 525 526 527

Argument The service specific parameters of the service request are transmitted in the argument. Data This parameter specifies the data value which is transferred over the SDCI interface. Permitted values: 0255

61131-9/WD V0.5 IEC 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 5.3 5.3.1 Transmitter/Receiver Description method

37

Working Draft

Status This parameter specifies supplementary information on the transfer status. Permitted values: PARITY_ERROR, FRAMING_ERROR, OVERRUN

The physical layer is specified by means of electrical and timing requirements. Electrical requirements specify signal levels and currents separately for Master and Device in the form of reference schematics. Timing requirements specify the signal transmission process (specifically the receiver) and a special signal detection function. 5.3.2 5.3.2.1 Electrical requirements General

The line driver is described by a reference schematic corresponding to Figure 12. On the Master side, a transmitter comprises a combination of two line drivers and one current sink. On the Device side, in its simplest form, the transmitter takes the form of a p-switching driver. As an option there can be an additional n-switching or non-switching driver (this also allows the option of push-pull output operation). In operating status ON the descriptive variables are the residual voltage VRQ, the standard driver current IQ, and the peak current IQPK. The source is controlled by the On/Off signal. An overload current event is indicated at the Overload output (OVD).

On/ Off

VRQ IQ IQPK

548 549 550 551 552 553

Overload

Figure 12 Line driver reference schematics The receiver is described by a reference schematic according to Figure 13. It performs the function of a comparator and is described by its switching thresholds VTH and a hysteresis VHYS between the switching thresholds. The output indicates the logic level (High or Low) at the receiver input.

VI VTH VHYS

H/L

554 555 556 557

V0

Figure 13 Receiver reference schematics Figure 14 shows the reference schematics for the interconnection of Master and Device for PHY-3W.

Working Draft
Device V+D ISD
On/ Off

38
Line L+ VD+L L+ ISM

61131-9/WD V0.5 IEC

Master V+M

VRQHD IQHD IQPKHD VRQHM IQHM IQPKHM

On/ Off

OVD

H/L

C/Q

VDQL

C/Q

H/L

VSD optional 1) VRQLD IQLD IQPKLD CQD VRQLM IQLM IQPKLM

On/ Off

VSM

VID

VIM

ILLM CQM

On/ Off

OVD

V0D

L-

VD0L

L-

V0M

558 559 560 561 562 563

Note 1) optional: low -side driver (push-pull only)

Figure 14 Master and Device reference schematics for PHY-3W The subsequent illustrations and parameter tables refer to the voltage level definitions in Figure 15. The parameter indices refer to the Master (M), Device (D) or line (L). The voltage drops on the line VD+ L , VDQ L and VD0 L are implicitely specified in 5.5 through cable parameters.
Device Line
VD+L VRQHD

Master
VRQHM

V+M

V+D

VSD

VDQL

VSM

VID VIM VRQLD V0D Output Input VD0L Input VRQLM Output V0M

564 565 566 567 568 5.3.2.2 Receiver

Figure 15 Voltage level definitions

The voltage range and switching threshold definitions are the same for Master and Device. The definitions in Table 4 apply.

61131-9/WD V0.5 IEC 569

Property VTHH D,M VTHL D,M VHYS D,M

39

Working Draft

Table 4 Electric characteristics of a receiver

Designation Input threshold 'H' Input threshold 'L' Hysteresis between input thresholds 'H' and 'L' Permissible voltage range 'L' Permissible voltage range 'H' Minimum 10,5 8 0 Typical n/a n/a n/a Maximum 13 11,5 n/a Unit V V V Remark See NOTE 1 See NOTE 1 Shall not be negative See NOTE 2 V0 D,M -1,0 n/a n/a V With reference to relevant negative supply voltage With reference to relevant positive supply voltage.

VIL D,M

VIH D,M

n/a

n/a

V+ D,M + 1,0

NOTE 1 NOTE 2

Thresholds are compatible with the definitions of type 1 digital inputs in IEC 61131-2. Hysteresis voltage VHYS = VTHH-VTHL

570 571 Figure 16 illustrates the switching thresholds for the detection of Low and High signals.
VID,M V+ Voltage range 'H'

VTHHMAX VTHLMAX VTHHMIN Threshold 'L' Voltage range 'L' VTHLMIN

Threshold 'H'

V0

572 573 574 575 576

Property VS M IS M

Figure 16 Switching thresholds 5.3.2.3 Master port

The definitions in Table 5 are valid for the electric characteristics of a Master port. Table 5 Electric characteristics of a Master port
Designation Supply voltage for Devices Supply current for Devices Current pulse capability for Devices Minimum 20 200 Typical 24 n/a Maximum 30 n/a Unit V mA External supply required for > 200 mA Master supply current capability for a minimum of 50 ms at 18 V after power-on of the port supply See NOTE 1 0 5 n/a n/a 15 15 mA mA Remark

ISIR M

400

n/a

n/a

mA

ILL M

Load or discharge current for 0 V < VI M < 5 V

Working Draft
Property Designation 5 V < VI M < 15 V 15 V< VI M < 30 V VRQH M Residual voltage 'H' Minimum 5 n/a

40
Typical n/a n/a Maximum 15 3

61131-9/WD V0.5 IEC

Unit mA V Voltage drop relating to V+ M at maximum driver current IQH M Voltage drop relating to V0 M at maximum driver current IQL M Remark

VRQL M

Residual voltage 'L'

n/a

n/a

IQH M IQPKH M IQL M IQPKL M CQ M NOTE 1 NOTE 2

DC driver current 'H' Output peak current 'H' DC driver current 'L' Output peak current 'L' Input capacitance

100 500 100 500 n/a

n/a n/a n/a n/a n/a

n/a n/a n/a n/a 1,0

mA mA mA mA nF Absolute value See NOTE 2 f=0 MHz to 4 MHz Absolute value See NOTE 2

Currents are compatible with the definition of type 1 digital inputs in IEC 61131-2 Wake-up request current (5.3.3.3).

577 578 579 580

Property VS D VS D

5.3.2.4

Device

The definitions in Table 6 are valid for the electric characteristics of a Device. Table 6 Electric characteristics of a Device
Designation Supply voltage Ripple Minimum 18 n/a Typical 24 n/a Maximum 30 1,3 Unit V V pp Peak-to-peak absolute value limits shall not be exceeded. f ripple = DC to 100 kHz VRQH D Residual voltage 'H' Residual voltage 'L' DC driver current P-switching output ("On" state) IQL D DC driver current N-switching output ("On" state) IQQ D Quiescent current to VO D ("Off" state) CQ D Input capacitance 0 n/a 1,0 nF 0 n/a 0 n/a n/a n/a 3 V Voltage drop compared with V+ D (IEC 60947-5-2) Voltage drop compared with V0 D Minimum value due to fallback to digital input in accordance with IEC 61131-2, type 2 Only for push-pull output stages Remark

VRQL D IQH D

n/a 50

n/a n/a

3 minimum (IQPKL M )

V mA

minimum (IQPKH M ) 15

mA

mA

Pull-down or residual current with deactivated output driver stages Effective capacitance between C/Q and L+ or L- of Device in receive state

61131-9/WD V0.5 IEC

Property Designation Minimum

41
Typical Maximum Unit

Working Draft
Remark (see NOTE)

NOTE Maximum of 10 nF capacitive load permissible for push-pull stages in the Device. In this case the limits are defined by the dynamic parameters (via the transmission rates supported by the Device). The value of 1 nF is applicable for a transmission rate of 230,4 kbit/s.

581 582 583 584 585 586 587 588 589 590 5.3.3 5.3.3.1 Timing requirements Transmission method

The Non Return to Zero (NRZ) modulation is used for the bit-by-bit coding. A logic value 1 corresponds to a voltage difference of 0 V between the C/Q line and L- line. A logic value "0" corresponds to a voltage difference of +24 V between the C/Q line and L- line. The open-circuit level on the C/Q line is 0 V with reference to L-. A start bit has logic value 0, i.e. +24 V with reference to L-. A UART frame is used for the character-by-character coding. The format of the SDCI UART frame is a bit string structured as shown in Figure 17.
Transmitted bit sequence Significance of information bits 0 Start bit (ST)

1st

2 20 lsb b0

10

11th

27 msb b1 b2 b3 b4 b5 b6 b7 P 1

Data octet Parity bit (even)

591 592 593 594 595 596 597 598 599 600 601 602 603

Key: lsb msb

least significant bit most significant bit

One stop bit (SP)

Figure 17 Format of an SDCI UART frame The definition of the UART frame format is based on ISO/IEC 1177:1985 and ISO/IEC 2022:1986. 5.3.3.2 Transmission characteristics

The timing characteristics of transmission are illustrated in the form of an eye diagram with the permissible signal ranges (see Figure 18). These ranges are applicable for receiver in both the Master and the Device. Regardless of boundary conditions, the transmitter shall generate a voltage characteristic on the receiver's C/Q connection that is within the permissible range of the eye diagram. The receiver shall detect bits as a valid signal shape within the permissible range of the eye diagram on the C/Q connection. Signal shapes in the no detection areas (below VTHL MAX or above VTHH MIN and within t ND ) shall not lead to invalid bits.

Working Draft
tH VIHD,M MAX V+D,M VTHHMAX VTHLMAX a) V0D,M VILD,M MIN tDR TBIT
a) no detection 'L' b) no detection 'H'

42
tND tL tND

61131-9/WD V0.5 IEC

Detection 'H'

b)

VTHHMIN VTHLMIN

Detection 'L'

tDF TBIT

604 605 606 607 608

Figure 18 Eye diagram for the 'H' and 'L' detection In order for a UART frame to be detected correctly, a signal characteristic as illustrated in Figure 19 is required on the receiver side. The signal delay time between the C/Q signal and the UART input shall be taken into account. Time T BIT always indicates the receiver's bit rate.
Start Bit n=1 TBIT VTHH VTHL Stop Bit n=11

Bit n=2

Bit n=3

Bit n=9

Bit n=10 TBIT

(2-r)TBIT

(3-r)TBIT (3-s)TBIT

(10-r)TBIT

(11-r)TBIT (11-s)TBIT

609 610 611 612 613 614 615 616 617 618 619 620

(1-s)TBIT

(2-s)TBIT

(10-s)TBIT

Figure 19 Eye diagram for the correct detection of a UART frame For every bit n in the bit sequence (n =111) of a UART frame, the time (n-r)T BIT (see Table 7 for values of r) designates the time at the end of which a correct level shall be reached in the 'H' or 'L' ranges as illustrated in the eye diagram in Figure 18. The time (n-s) T BIT (see Table 7 for values of s) describes the time, which shall elapse before the level changes. Reference shall always be made to the eye diagram in Figure 18, where signal characteristics within a bit time are concerned. This representation permits a variable weighting of the influence parameters "transmission rate accuracy", "bit-width distortion", and "slew rate" of the receiver. Table 7 specifies the dynamic characteristics of the transmission.

61131-9/WD V0.5 IEC 621

Property f DTR

43

Working Draft

Table 7 Dynamic characteristics of the transmission

Designation transmission rate Minimum n/a Typical 4,8 38,4 230,4 208,33 26,04 4,34 Maximum n/a Unit kbit/s COM1 COM2 COM3 Remark

T BIT

Bit time at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s Master transmission rate accuracy at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s Start of detection time within a bit with reference to the raising edge of the start bit End of detection time within a bit with reference to the raising edge of the start bit Rise time at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s

s s s Tolerance of the transmission rate of the Master T BIT /T BIT Calculated in each case from the end of a bit at a UART sampling rate of 8 (see NOTE) Calculated in each case from the end of a bit at a UART sampling rate of 8 (see NOTE) With reference to the bit time unit

f DTRM

-0,1 -0,1 -0,1 0,65

n/a n/a n/a n/a

+0,1 +0,1 +0,1 n/a

% % % -

n/a

n/a

0,22

T DR

0 0 0 0 0 0 0 0 n/a

n/a n/a n/a n/a n/a n/a n/a n/a n/a

0,20 41,7 5,2 869 0,20 41,7 5,2 869 1/16

T BIT s s ns T BIT s s ns T BIT

T DF

Fall time at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s

With reference to the bit time unit

t ND

Noise suppression time

Permissible duration of a receive signal above/below the detection threshold without detection taking place Duration of a receive signal above the detection threshold for 'H' level Duration of a receive signal below the detection threshold for 'H' level

tH

Detection time High

1/16

n/a

n/a

T BIT

tL

Detection time Low

1/16

n/a

n/a

T BIT

NOTE The parameters r and s apply to the respective Master or Device receiver side. This definition allows for a more flexible definition of oscillator accuracy, bit distortion and slewrate on the Device side. The over-all bit-width distortion on the last bit of the UART frame shall provide a correct level in the range of Figure 19.

622 623 624 625 626 627 5.3.3.3 Wake-up current pulse

The wake-up feature initiates the changeover of a Device to a ready-to-receive state. A service call (PL_WakeUp.req) from the DL initiates the wake up process (see 5.2.2.2). The wake-up request (WURQ) starts with a current pulse induced by the Master (port) for a time T WU . The wake-up request comprises the following phases (Figure 20):

Working Draft 628 629 630 631 632 633 634

44

61131-9/WD V0.5 IEC

a) Injection of a current IQ WU by the Master depending on the level of the C/Q connection. For an input signal equivalent to logic 1 this is a current source; for an input signal equivalent to logic 0 this is a current sink. b) Delay time of the Device until it is ready to receive. The wake-up request pulse can be detected by the Device through a voltage change on the C/Q line or evaluation of the current of the respective driver element within the time T WU . Figure 20 shows examples for Devices with low output power.
SIO Mode Device output Q = low V a) Wake-up request b) undefined High impedance, low level Receiver enabled

Q = high

undefined

High impedance, low level

TWU

T TREN

635 636 637 638 639

Property IQWU Designation Amplitude of Masters wake-up current pulse Duration of Master's wake-up current pulse Receive enable delay

Figure 20 Wake-up request Table 8 specifies the current and timing properties associated with the wake-up request. See Table 5 for values of IQPKL M and IQPKH M . Table 8 Wake-up request characteristics
Minimum IQPKLM or IQPKHM 75 n/a 85 s Typical n/a Maximum n/a Unit mA Remark Current pulse followed by switching status of Device Master property

TWU

TREN

n/a

n/a

500

Device property

640 641 642 643 644 5.4 5.4.1 Power supply Power-on requirements

Figure 21 illustrates how the power-on behavior of a Device is defined by the ramp-up time of the power supply and by the Device internal time to get ready for the wake-up operation.

61131-9/WD V0.5 IEC

VS

45

Working Draft

VSD,M min

Ready for wake-up

645 646 647 648 649

Property T RDL Designation Wake-up readiness following power-on

TRDL

Figure 21 Power-on timing Upon power-on it is mandatory for a Device to reach the wake-up ready state within the time limits defined in Table 9. Table 9 Power-on timing
Minimum n/a Typical n/a Maximum 300 ms Unit Remark Device ramp-up time until it is ready for wake-up signal detection See NOTE

NOTE

Equivalent to the time delay before availability in IEC 60947-5-2.

650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 5.4.2 Master powered Device

The 3-wire cable connection allows for a power supply independent from the communication line. The maximum supply current for a Device is defined by the maximum driver current per port of the Master as defined in Table 5. 5.4.3 External power supply

The Device may be separately and additionally supplied with power. The communication section of the Device (PHY-3W) shall always be Master powered. 5.5 5.5.1 Medium Connector

The Master and Device pin assignment is based on the specifications in IEC 60947-5-2, with extensions specified in the paragraphs below. For a Master, two port classes are defined, port class A and port class B. Port class B is mainly intended for power Devices (see Figure 23).
NOTE Port class A and port class B are not compatible.

Port class A uses M5, M8, and M12 connectors, with a maximum of four pins. Port class B only uses M12 connectors with 5 pins. Female connectors are assigned to the Master and male connectors to the Device. Table 10 lists the pin assignments and Figure 22 illustrates the layout and mechanical coding for M12, M8 and M5 connections. M12 connectors are mechanically "A"-coded according to IEC 61076-2-101.

Working Draft 670

Pin 1 2 Signal L+ I/Q P24 Designation Power supply (+)

46 Table 10 Pin assignments

Remark See Table 6 1: 2: 3: 4:

61131-9/WD V0.5 IEC

NC/DI/DO (port class A) Option P24 (port class B) Option Option Option Power supply (-) SIO/SDCI NC (port class A) N24 (port class B)

NC (not connected) DI DI, then configured DO Extra power supply for power Devices (port class B)

3 4 5

LC/Q NC N24

See Table 6 Standard I/O mode or SDCI Option 1: Shall not be connected on the Master side (port class A). Option 2: Reference to the extra power supply (port class B)

NOTE M12 is always a 5 pin version on the Master side (female).

671
Class A
4 3

Class A
2 4

Class A
2 1 3 3 5 4

Class B
2 1

Male (Device)
1 2

M5
3 4 4

M8
2 1

M12-4
2 1 3

M12-5
2

Female (Master)

3 5 4

5 4

M5

M8

M12-5

M12-5

672 673 674 675 676 677

M12 connectors are "A"-coded according to IEC 61076-2-101

Figure 22 Pin layout front view Figure 23 shows the layout of the two port classes A and B. Class B ports shall be marked unambiguously due to the incompatibilities. Port class A allows power consumption of 200 mA, the extra power supply of port class B allows 3,5 A for M12 or more with wire connections.

61131-9/WD V0.5 IEC

Port Class A (M12) 2 I/Q 1 4 C/Q 3 5 Power 1
SDCI power supply

47

Working Draft

PIN 2: PIN 2:

PIN 5: PIN 5: PIN 4: PIN 4:

Option 1: NC (not connected) Option 1: NC (not connected) Option 2: DI Option 2: DI Option 3: DI configured DO Option 3: DI configured DO NC NC DI; SDCI/SIO; DO DI; SDCI/SIO; DO

Port Class B (M12) 2 1 4 C/Q 3 5

P24 (Act)

Protection Power 2 Power 1

SDCI power supply Power Device power supply

PIN 2: PIN 2:

P24 (extra power supply for P24 (extra power supply for power Devices, current is power Devices, current is manufacturer dependent) manufacturer dependent) N24 (0 V, power Device) N24 (0 V, power Device) DI; SDCI/SIO; DO DI; SDCI/SIO; DO

PIN 5: PIN 5: PIN 4: PIN 4:

678 679 680 681 682 683 684 685 5.5.2

N24 (Act)

Figure 23 Class A and B port definitions Cable

The transmission medium for SDCI communication is a multi-wired cable with 3 or more wires. The definitions in the following section implicitly cover the static voltage definitions in Table 4 and Figure 15. To ensure functional reliability, the cable properties shall comply with Table 11. Table 11 Cable characteristics
Property Length Overall loop resistance RLeff Effective line capacitance CLeff 0 n/a n/a Minimum n/a n/a n/a Typical 20 6,0 3,0 Maximum m nF (<1 MHz) Unit

686 687 688 The loop resistance RL eff and the effective line capacitance CL eff may be measured as illustrated in Figure 24.
RLeff CLeff L+ C/Q LL

689 690 691

Figure 24 Reference schematic for effective line capacitance and loop resistance Table 12 shows the cable conductors and their assigned color codes.

Working Draft 692

Signal LC/Q L+ I/Q P24 N24 NOTE

48 Table 12 Cable conductor assignments

Designation Power supply (-) Communication signal Power supply (+) DI or DO Extra power supply (+) Extra power supply (-) Color Blue Black Brown White Any other Any other PHY-3W PHY-3W PHY-3W Optional Optional Optional

61131-9/WD V0.5 IEC

Remark

Corresponding to IEC 60947-5-2

693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709

Standard Input and Output (SIO)

Figure 80 and Figure 90 demonstrate how the SIO mode allows a Device to bypass the SDCI communication layers and to map the DI or DO signal directly into the data exchange message of the higher level fieldbus or system. Changing between the SDCI and SIO mode is defined by the user configuration or implicitly by the services of the Master applications. The system management takes care of the corresponding initialization or deactivation of the SDCI communication layers and the physical layer (mode switch). The characteristics of the interfaces for the DI and DO signals are derived from IEC 61131-2, type 1.

7
7.1

Data link layer

General

The data link layers of SDCI are concerned with the delivery of frames between a Master and a Device across the physical link. It uses several F-sequence ("frame sequence") types for different data categories. A set of DL-Services is offered to the application layers and PLServices are used to control the physical layer. The data link layer takes care of the error detection of messages and the appropriate remedial measures (e.g. retry). Figure 25 represents the structure and the services of the Master's data link layer.

61131-9/WD V0.5 IEC

49
Application Layer
DL_PDInputTransport

Working Draft

DL_ReadParam

DL_WriteParam

System Management
DL_Read DL_Write DL_SetMode

On-request data handler

EventFlag.ind

DL_Event

Process data handler DL-B

PD.req PD.cnf PDTrig

CMD.req

CMD.cnf

ComTrig

PDValid

DL_Mode Port x handler

Master DL-mode handler

FHInfo CMD.req CMD.cnf

Frame handler
DI / DO PL_Transfer.req PL_Transfer.ind

PL_Mode.req Mode switch Inactive

PL_WakeUp.req

(Wake-up)

(Coded switching)

DL_PDCycle

DL_PDOutputUpdate

DL_ISDUTransport

DL_ISDUAbort

DL_Control

DL_Event Conf

DL-A

(Switching signal)

710 711 712

Physical Layer (port)

Figure 25 Structure and services of the data link layer (Master) Figure 26 represents the structure and the services of the Device's data link layer.

Application Layer
DL_PDOutputTransport

DL_PDInputUpdate

DL_WriteParam

On-request data handler

DL_Read DL_Write Line handler DL_Mode EventFlag

Process data handler DL-B

PD.req PD.rsp

CMD.ind

CMD.rsp

PDValid

DL_PDCycle

DL_Control

DL_ReadParam

DL_ISDUTransport

DL_ISDUAbort

DL_Event

DL_EventTrigger

System Management

Device DL-mode handler

DL-A

FHInfo CMD.ind CMD.rsp

Frame handler
DI/DO PL_Transfer.ind PL_Transfer.req

PL_Mode.req Mode switch

PL_WakeUp.ind

(Wake-up)

(Coded switching)

(Switching signal)

713 714 715 716 717 718 719 720 721

Physical Layer

Figure 26 Structure and services of the data link layer (Device) The data link layers are structured due to the nature of the data categories into process data handlers and on-request data handlers which are in turn using a frame handler to deal with the requested transmission frames. The special modes of Master ports such as Wake-up, SDCI, SIO (disable communication) require a dedicated DL-mode handler within the Master data link layer. The special wake-up signal modulation requires signal detection on the Device side and thus a DL-mode handler within the Device data link layer. Each handler comprises its own state machine if appropriate.

Working Draft 722 723 724 725 726 727 728 729 730 731

50

61131-9/WD V0.5 IEC

The data link layer is subdivided in a DL-A with its own internal services and a DL-B with the external services. 7.2 7.2.1 7.2.1.1 Data link layer services DL-B services Overview of services within Master and Device

This clause defines the services of the data link layer to be provided to the application layer and system management via its external interfaces. Table 13 lists the assignments of Master and Device to their roles as initiator or receiver for the individual DL services. Empty fields indicate no availability of this service on Master or Device. Table 13 Service assignments within Master and Device
Service name DL_ReadParam DL_WriteParam DL_ISDUTransport DL_ISDUAbort DL_PDOutputUpdate DL_PDOutputTransport DL_PDInputUpdate DL_PDInputTransport DL_PDCycle DL_SetMode DL_Mode DL_Event DL_EventConf DL_EventTrigger DL_Control DL_Read DL_Write Key (see 3.3.4) I Initiator of service R Receiver (responder) of service I/R R R I I R I I R R R/I I I I R I Master R R R R R I R Device I I I I

732 733 734 735 736 737 See 3.3 for conventions and how to read the following service descriptions in this document. 7.2.1.2 DL_ReadParam

The DL_ReadParam service is used to read a parameter value from the Device via the page communication channel. The parameters of the service primitives are listed in Table 14. Table 14 DL_ReadParam
Parameter name Argument Address .req M M .cnf .ind M M

Result (+)

61131-9/WD V0.5 IEC

Parameter name Value

51
.req .cnf M .ind

Working Draft

Result (-) ErrorInfo

S M

738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758

Argument The service-specific parameters of the service request are transmitted in the argument. Address This parameter specifies the address of the requested parameter, i.e. the parameter addresses within the page communication channel. Permitted values: 0 to 31 Result (+): This selection parameter indicates that the service request has been executed successfully. Value This parameter specifies read parameter values. Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.1.3

DL_WriteParam

The DL_WriteParam service is used to write a parameter value to the Device via the page communication channel. The parameters of the service primitives are listed in Table 15. Table 15 DL_WriteParam
Parameter name Argument Address Value .req M M M .cnf .ind M M M

Result (+)

Result (-) ErrorInfo

S M

759 760 761 762 763 764 765 766

Argument The service-specific parameters of the service request are transmitted in the argument. Address This parameter specifies the address of the requested parameter, i.e. the parameter addresses within the page communication channel. Permitted values: 16 to 31, in accordance with parameter access rights Value

Working Draft 767 768 769 770 771 772 773 774 775 776 777 778 779 7.2.1.4 DL_Read

52

61131-9/WD V0.5 IEC

This parameter specifies the parameter value to be written. Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the result parameter. Permitted values: NO_COMM, STATE_CONFLICT

The DL_Read service is used to read a parameter value from the Device via the page communication channel. The parameters of the service primitives are listed in Table 16. Table 16 DL_Read
Parameter name Argument Address .req M M .cnf .ind M M

Result (+) Value

S M

Result (-) ErrorInfo

S M

780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799

Argument The service-specific parameters of the service request are transmitted in the argument. Address This parameter specifies the address of the requested parameter, i.e. the parameter addresses within the page communication channel. Permitted values: 0 to 15, in accordance with parameter access rights Result (+): This selection parameter indicates that the service request has been executed successfully. Value This parameter specifies specifies read parameter values. Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.1.5

DL_Write

The DL_Write service is used to write a parameter value to the Device via the page communication channel. The parameters of the service primitives are listed in Table 17.

61131-9/WD V0.5 IEC 800

53 Table 17 DL_Write
Parameter name .req M M M .cnf .ind M M M

Working Draft

Argument Address Value

Result (+)

Result (-) ErrorInfo

S M

801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823

Argument The service-specific parameters of the service request are transmitted in the argument. Address This parameter specifies the address of the requested parameter, i.e. the parameter addresses within the page communication channel. Permitted values: 0 to 15, in accordance with parameter access rights Value This parameter specifies the parameter value to be written. Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.1.6

DL_ISDUTransport

The DL_ISDUTransport service is used to transport an ISDU. This service is used by the Master to send a service request from the Master application layer to the Device. It is used by the Device to send a service response to the Master from the Device application layer. The parameters of the service primitives are listed in Table 18. Table 18 DL_ISDUTransport
Parameter name Argument ValueList .req M M .ind M M .cnf .res

Result (+) Data

S C

S C

Result (-) ErrorInfo

S M

S M

Working Draft 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 7.2.1.8 DL_PDOutputUpdate 7.2.1.7 DL_ISDUAbort

54

61131-9/WD V0.5 IEC

Argument The service-specific parameters of the service request are transmitted in the argument. ValueList This parameter specifies the relevant operating parameters Parameter type: Record Index Permitted values: 2 to 65 535 (See B.2.1 for constraints) Subindex Permitted values: 0 to 255 Data Parameter type: Octet string Direction Permitted values: READ, WRITE Result (+): This selection parameter indicates that the service request has been executed successfully. Data Parameter type: Octet string Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the result parameter. Permitted values: NO_COMM, STATE_CONFLICT, TIMEOUT, NO_ISDU_SUPPORTED, VALUE_OUT_OF_RANGE

The DL_ISDUAbort service aborts the actual ISDU transmission. This service has no parameters. The service returns with the confirmation after abortion of the ISDU transmission.

The Masters application layer uses the DL_PDOutputUpdate service to update the output data (process data from Master to Device) on the data link layer. The parameters of the service primitives are listed in Table 19. Table 19 DL_PDOutputUpdate
Parameter name Argument OutputData .req M M .cnf

Result (+) TransportStatus

S M

61131-9/WD V0.5 IEC

55
Parameter name .req .cnf

Working Draft

Result (-) ErrorInfo

S M

864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886

Argument The service-specific parameters of the service request are transmitted in the argument. OutputData This argument specifies the process data provided by the application layer. Parameter type: Octet string Result (+): This selection parameter indicates that the service request has been executed successfully. TransportStatus This parameter indicates whether the data link layer is in a state permitting data to be transferred to the communication partner(s). Permitted values: YES, NO Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.1.9

DL_PDOutputTransport

The data link layer on the Device uses the DL_PDOutputTransport service to transfer to the application layer the content of output data (process data from Master to Device). The parameters of the service primitives are listed in Table 20. Table 20 DL_PDOutputTransport
Parameter name Argument OutputData .ind M M

887 888 889 890 891 892 893 894 895 896 897

Argument The service-specific parameters of the service request are transmitted in the argument. OutputData This argument specifies the process data to be transmitted to the application layer. Parameter type: Octet string

7.2.1.10

DL_PDInputUpdate

The Device's application layer uses the DL_PDInputUpdate service to update the input data (process data from Device to Master) on the data link layer. The parameters of the service primitives are listed in Table 21.

Working Draft 898

56 Table 21 DL_PDInputUpdate
Parameter name Argument InputData .req M M

61131-9/WD V0.5 IEC

.cnf

Result (+) TransportStatus

S M

Result (-) ErrorInfo

S M

899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920

Argument The service-specific parameters of the service request are transmitted in the argument. InputData This argument specifies the process data provided by the application layer. Result (+): This selection parameter indicates that the service request has been executed successfully. TransportStatus This parameter indicates whether the data link layer is in a state permitting data to be transferred to the communication partner(s). Permitted values: YES, NO Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.1.11

DL_PDInputTransport

The data link layer on the Master uses the DL_PDInputTransport service to transfer to the application layer the content of input data (process data from Device to Master). The parameters of the service primitives are listed Table 22. Table 22 DL_PDInputTransport
Parameter name Argument InputData .ind M M

921 922 923 924 925 926 927

Argument The service-specific parameters of the service request are transmitted in the argument. InputData This argument specifies the process data to be transmitted to the application layer. Parameter type: Octet string

61131-9/WD V0.5 IEC 928 929 930 931 932 933 934 935 936 7.2.1.13 DL_SetMode 7.2.1.12 DL_PDCycle

57

Working Draft

The data link layer uses the DL_PDCycle service to indicate the end of a process data cycle to the application layer. This service has no parameters.

The DL_SetMode service is used to trigger the data link layer's state machine. In addition, system management sends the characteristic values required for operation to the data link layer. The parameters of the service primitives are listed in Table 23. Table 23 DL_SetMode
Parameter name Argument Mode ValueList .req M M U .cnf

Result (+)

Result (-) ErrorInfo

S M

937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963

Argument The service-specific parameters of the service request are transmitted in the argument. Mode This parameter specifies the requested mode of the Master's DL on an individual port. Permitted values: INACTIVE, STARTUP, PREOPERATE, OPERATE ValueList This parameter specifies the relevant operating parameters. Data structure: record F-sequenceTime: (to be propagated to frame handler) F-sequenceType: (to be propagated to frame handler) Permitted values: TYPE_0, TYPE_1_1, TYPE_1_2, TYPE_1_V, TYPE_2_2, TYPE_2_3, TYPE_2_4, TYPE_2_5, TYPE_2_6, TYPE_2_V PDInputLength: (to be propagated to frame handler) PDOutputLength: (to be propagated to frame handler) OnReqDataLengthPerFrame: (to be propagated to frame handler) Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the result parameter. Permitted values: NOT_CONNECTED, STATE_CONFLICT, PARAMETER_CONFLICT TYPE_2_1,

Working Draft 964 965 966 967 968 969 7.2.1.14 DL_Mode
NOTE

58

61131-9/WD V0.5 IEC

TYPE_1_1 forces interleave mode of process and on-request data transmission, see 7.3.4.2

The DL uses the DL_Mode local service to report to system management that an operating status has been reached. The parameters of the service primitives are listed in Table 24. Table 24 DL_Mode
Parameter name Argument RealMode .ind M M

970 971 972 973 974 975 976 977 978 979 980 981 982

Argument The service-specific parameters of the service request are transmitted in the argument. RealMode Indicates the status of the DL-mode handler. Permitted values: INACTIVE, COM1, COM2, COM3, COMMLOSS, STARTUP, PREOPERATE, OPERATE

7.2.1.15

DL_Event

The service DL_Event indicates a pending status or error information. The source of the event is remote (Device). The event is triggered by a Device application. The parameters of the service primitives are listed in Table 25. Table 25 DL_Event
Parameter name Argument Instance Type Mode EventCode EventsLeft .req M M M M M .ind M M M M M M

983 984 985 986 987 988 989 990 991 992 993 994

Argument The service-specific parameters of the service request are transmitted in the argument. Instance This parameter specifies the Event source. Permitted values: DL, AL, APP Type This parameter specifies the Event category. Permitted values: ERROR, WARNING, MESSAGE Mode This parameter specifies the Event type. Permitted values: SINGLESHOT, APPEARS, DISAPPEARS

61131-9/WD V0.5 IEC 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 7.2.1.18 DL_Control 7.2.1.17 DL_EventTrigger 7.2.1.16 DL_EventConf

59

Working Draft

EventCode This parameter contains a code identifying the event. Parameter type: 16 bit unsigned integer EventsLeft This parameter contains a code indicating the number of unprocessed events.

The DL_EventConf service confirms the transmitted events via the event handler. This service has no parameters.

The DL_EventTrigger service starts the event signaling and freezes the event buffer. After release of the event buffer the service returns and unfreezes the event buffer. This service has no parameters. The service returns with the confirmation after release of the event buffer.

The Master uses the DL_Control service to convey control information to and from the corresponding technology specific Device application. The parameters of the service primitives are listed in Table 26. Table 26 DL_Control
Parameter name Argument ControlCode .req M M .ind M M(=)

1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030

Argument The service-specific parameters are transmitted in the argument. ControlCode This parameter contains a code identifying the event. Permitted values: PD_VALID, PD_INVALID

7.2.2 7.2.2.1

DL-A services Overview

According to 7.1 the data link layer is split into the upper layer DL-B and the lower layer DL-A. The layer DL-A comprises the frame handler as shown in Figure 25 and Figure 26. The frame handler encodes commands and data into messages and sends these to the connected Device via the physical layer. It receives messages from the Device via the physical layer and forwards their content to the corresponding handlers in the form of a confirmation. When the event flag is set, the cyclic frame handler generates an event.

Working Draft 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040

60

61131-9/WD V0.5 IEC

The Master frame handler shall employ a retry strategy following a corrupted message, i.e. upon receiving an incorrect checksum from a Device, or no checksum at all. In case of a perturbed message the Master shall repeat the Master message two times ( Table 91). If the retries are not successful, a negative confirmation shall be provided and the Master shall reinitiate the communication via the Port-x handler beginning with Wake-up. The frame handler performs cyclic operation with the F-sequence type and cycle time provided by the DL_SetMode service. Table 27 lists the assignment of Master and Device to their roles as initiator or receiver in the context of the execution of their individual DL-A services. Table 27 DL-A services within Master and Device
Service name CMD PD EventFlag PDValid FHInfo ComTrig PDTrig Master R R I I I I I Device I I R R I

1041 1042 1043 1044 1045 1046

Parameter name Argument RWDirection ComChannel AddressCtrl Length Data

7.2.2.2

CMD

The CMD service is used to set-up the on-request data for the next message to be sent. In turn, the confirmation of the service contains the data from the receiver. The parameters of the service primitives are listed in Table 28. Table 28 CMD
.req M M M M M C .ind M M M M M C M C .rsp M .cnf M

Result (+) Data Length

S C M

Result (-) ErrorInfo

S M

1047 1048 1049 1050 1051

Argument The service-specific parameters of the service request are transmitted in the argument. RWDirection This parameter specifies the read or write direction.

61131-9/WD V0.5 IEC 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082
Parameter name Argument PDInAddress PDInLength PDOut PDOutAddress PDOutLength

61

Working Draft

Permitted values: READ, WRITE ComChannel This parameter specifies the selected communication channel for the transmission. Permitted values: DIAGNOSIS, PAGE, ISDU AddressCtrl This parameter specifies the address or flow control value. Permitted values: 0 to 31 Length This parameter specifies the data length to transmit. Permitted values: 0 to 32 Data This parameter specifies the data to transmit. Data type: Octet string Result (+): This selection parameter indicates that the service request has been executed successfully. Data This parameter contains the read data values. Length This parameter contains the length of the received data package. Permitted values: 0 to 32 Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.2.3

PD

The PD service is used to set-up the data to be sent through the process communication channel. The confirmation of the service contains the data from the receiver. The parameters of the service primitives are listed in Table 29. Table 29 PD
.req M C C C C C .ind M C(=) C(=) C(=) C(=) C(=) .rsp .cnf

Result (+) PDIn

S C

S C(=)

Working Draft
Parameter name Result (-) ErrorInfo

62
.req .ind

61131-9/WD V0.5 IEC

.rsp S M .cnf S M(=)

1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117

Argument The service-specific parameters of the service request are transmitted in the argument. PDInAddress This parameter contains the address of the requested process data. PDInLength This parameter contains the length of the requested process data. Permitted values: 0 to 32 PDOut This parameter contains the process data to be transferred from Master to Device. Data type: Octet string PDOutAddress This parameter contains the address of the transmitted process data PDOut. PDOutLength This parameter contains the length of the transmitted process data PDOut. Permitted values: 0 to 32 Result (+) This selection parameter indicates that the service request has been executed successfully. PDIn This parameter contains the process data to be transferred from Device to Master. Data type: Octet string Result (-) This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information supplementing the result parameter. Permitted values: NO_COMM, STATE_CONFLICT

7.2.2.4

EventFlag

The EventFlag service signals the occurrence of the event flag during cyclic communication within the Device's response. This service has no parameters.

7.2.2.5

PDValid

The service PDValid changes the state of the validity qualifier of the PDIn process data. The parameters of the service primitives are listed in Table 30.

61131-9/WD V0.5 IEC 1118

63 Table 30 PDValid
Parameter name .req .ind

Working Draft

Argument PDState M M

1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129

Argument The service-specific parameters are transmitted in the argument. PDState This parameter indicates the validity of the transmitted PDIn process data. Permitted values: PD_VALID, PD_INVALID

7.2.2.6

FHInfo

The service FHInfo signals an exceptional operation within the frame handler. The parameters of the service are listed in Table 31. Table 31 FHInfo
Parameter name Argument FHInfo M .ind

1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142

Argument The service-specific parameters are transmitted in the argument. FHInfo This parameter indicates the exception within the frame handler. Permitted values: COMMLOST, ILLEGAL_FRAME_TYPE

7.2.2.7

ComTrig

The service ComTrig is only available on the Master. The service triggers an immediate call of the CMD.req service to provide the on-request data for the next Master message. The parameters of the service are listed in Table 32.

Table 32 ComTrig
Parameter name Argument DataLength M .ind

1143 1144 1145 1146 1147

Argument The service-specific parameters are transmitted in the argument. DataLength This parameter contains the available amount of on-request data per message.

Working Draft 1148 1149 1150 1151 1152 7.2.2.8 PDTrig

64

61131-9/WD V0.5 IEC

The service PDTrig is only available on the Master. The service triggers an immediate call of the PD.req service to provide the on-request data for the next Master message. The parameters of the service are listed in Table 33. Table 33 PDTrig
Parameter name Argument DataLength M .ind

1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171

Argument The service-specific parameters are transmitted in the argument. DataLength This parameter contains the available amount of on-request data per message.

7.3 7.3.1

Data link layer protocol Overview

Figure 25 and Figure 26 are showing the structure of the data link layer and its components; a DL-mode handler, a frame handler, a process data handler, and an on-request data handler to provide the described services. The following sections define the behaviour (dynamics) of these handlers by means of UML state machines and transition tables. The on-request handler supports three independent types of data: service, command and event. Therefore, three additional state machines are working together with the on-request handler state machine as shown in Figure 27. Supplementary sequence or activity diagrams are illustrating certain use cases. See [4] and [5]. The elements each handler is dealing with, such as frames, wake-up procedures, interleave mode, ISDU (Indexed Service Data Units), and events are defined within the context of the respective handler.
State machine: State machine: Service handler Service handler State machine: State machine: Command handler Command handler State machine: State machine: On-request handler On-request handler State machine: State machine: Event handler Event handler

State machine: State machine: Process data handler Process data handler

1172 1173

State machine: State machine: DL-mode handler DL-mode handler

State machine: State machine: Frame handler Frame handler

Figure 27 State machines of the data link layer

61131-9/WD V0.5 IEC 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 7.3.2 7.3.2.1 DL-mode handler General

65

Working Draft

The Master DL-mode handler shown in Figure 25 is responsible to setup the SDCI communication using services of the Physical Layer (PL) and the CMD service ( 7.2.2.2) to control and monitor the frame handler. The Device DL-mode handler shown in Figure 26 is responsible to detect a wake-up request and to establish communication using the CMD service. 7.3.2.2 Wake-up procedures and Device conformity rules

System Management triggers the following actions on the data link layer with the help of the DL_SetMode service (Mode = STARTUP). The Master DL-mode handler tries to establish communication via a wake-up request (PL_WakeUp.req) followed by a message with read F-sequence TYPE_0 (MinCycleTime) according to the sequence presented in Figure 28.
TREN
WURQ Master

Master start-up

TDMT

TDMT
COM2

TDMT
COM1

COM3 SIO

Device start-up

1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203

Device

Figure 28 Example of an attempt to establish communication After the wake-up request (WURQ), defined in 5.3.3.3, the DL-mode handler requests the frame handler to send the first read message after a time T REN (Table 8) and T DMT (Table 34). The defined transmission rates COM1, COM2, COM3 are used in descending order until a response is obtained, as shown in the example of Figure 28: Step : Master message with COM3 (Table 7). Step : Master message with COM2 (Table 7). Step : Master message with COM1 (Table 7). Step : Device response message with COM1. Before initiating a (new) message, the DL-mode handler shall wait at least for a time of T DMT . T DMT is defined in Table 34. The following conformity rule applies for Devices regarding support of transmission rates: A Device shall support one of the transmission rates COM1, COM2, and COM3. If an attempt to establish communication fails, the Master DL-mode handler shall not start a new retry wake-up procedure until after a time T DWU as shown in Figure 29 and defined in Table 34.

Working Draft

66

61131-9/WD V0.5 IEC

WURQ Master

WURQ

COM3 SIO Device

COM2

COM1 No response

1204 1205 1206 1207 1208 1209

TDWU

Figure 29 Failed attempt to establish communication The Master shall make up to n WU +1 successive wake-up requests as shown in Figure 30. If this initial wake-up retry sequence fails, the Device shall reset its C/Q line to SIO mode after a time T DSIO (T DSIO is retrigged in the Device after each detected WURQ). The Master shall not trigger a new wake-up retry sequence until after a time T SD .
Wake-up retry sequence

SIO Master

Device

TDSIO TDSIO TDSIO TSD

1210 1211 1212 1213 1214 1215 1216

Property T DMT T DSIO

Figure 30 Retry strategy to establish communication The DL of the Master shall request the PL to go to DI mode after a failed wake-up retry sequence. The values for the timings of the wake-up procedures and retries are defined in Table 8 and the following Table 34. They are defined from a Master's point of view. Table 34 Wake-up procedure and retry characteristics
Designation Master message delay Standard IO delay Wake-up retry delay Wake-up retry count Device detection time Characteristic of the Master Minimum 27 60 Typical n/a n/a Maximum 37 300 Unit T BIT ms Remark Bit time of subsequent data transmission rate After T DSIO the Device falls back to SIO mode (if supported) 30 2 0,5 n/a 2 n/a 50 2 1 s ms After T DWU the Master repeats the wake-up request Number of wake-up request retries Time between 2 wake-up request sequences. See NOTE

T DWU n WU T SD

NOTE

61131-9/WD V0.5 IEC 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227

67

Working Draft

The Masters data link layer shall stop the establishing communication procedure once it finds a communicating Device, and reports the detected COM-Mode using a DL_Mode indication. If the procedure fails, a corresponding error is reported using the same service. 7.3.2.3 Fallback procedure

System Management induces the following actions on the data link layer with the help of the DL_SetMode service (Mode = INACTIVE): A MasterCommand "Fallback" (Table B.2) forces the Device to switch into the SIO mode. The Devce shall accomplish the transition to the SIO mode after 3 MasterCycleTimes and/or within 500 ms after the MasterCommand "Fallback". This allows for possible retries if the MasterCommand failed indicated through a negative Device response.

Figure 31 shows the fallback procedure and its retry and timing constraints.
MasterCommand "Fallback" Possible retries

Master

SIO Device Master Cycle Time

TFBD

1228 1229 1230 1231

Property T FBD

Figure 31 Fallback procedure Table 35 shows the fallback timing characteristics. See A.2.6 for details. Table 35 Fallback timing characteristics
Designation Fallback delay Minimum 3 MasterCycleTimes (operate state) or 3 T initcyc (preoperate state) Typical n/a Maximum 500 Unit ms Remark After a time T FBD the Device shall be switched to SIO mode (see Figure 31)

1232 1233 1234 7.3.2.4 Master state machine of the DL-mode handler

Figure 32 shows the Master state machine of the DL-mode handler.

Working Draft

68

61131-9/WD V0.5 IEC

/Initialization DL_SetMode_INACTIVE/ T8 DL_SetMode_INACTIVE/ T13

Idle_0

DL_SetMode_STARTUP/ T1 EstablishCom_1

[Retry = 3]/ T5

Submachine 1 "WakeUp"

enex_4 FHInfo_COMLOST/ T14

enex_1

enex_2

enex_3

[Response COM3]/ T2

[Response COM2]/ T3

[Response COM1]/ T4

Startup_2 FHInfo_COMLOST/ T9 DL_SetMode_ STARTUP/ T12 DL_SetMode_PRE OPERATE/ T6 DL_SetMode _OPERATE/ T11 Operate_4 DL_SetMode_OPERATE/ T10

DL_SetMode _STARTUP/ T7

PreOperate_3

1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247
NOTE

Figure 32 Master state machine of the DL-mode handler

The conventions of the UML diagram types are defined in 3.3.6.

The DL-mode handler shall first establish communication via a "WakeupRequest" command. This procedure is specified by submachine 1 in Figure 33. The purpose of state "Startup_2" is to check a Device's identity via the data of the direct parameter page (Figure 4). In state "PreOperate_3", the Master assigns parameters to the Device using ISDUs. Cyclic exchange of process data is performed in state "Operate". Within this state additional on-request data such as ISDUs, commands, and events can be communicated using appropriate F-sequence types (Figure 36). The states 3 and 4 provide no explicit functionality, but show different availabilities of subsidiary state machines.

61131-9/WD V0.5 IEC

69
EstablishCom_1

Working Draft

tm(Tdwu)[Retries < 3]/ T19

WURQ_5

tm(Tdmt)/ T15 ComRequestCOM3_6

[Response COM3]/ T2 enex_1

tm(Tdmt)[NoResponse]/ T16 ComRequestCOM2_7 [Response COM2]/ T3 enex_2 tm(Tdmt)[NoResponse]/ T17 ComRequestCOM1_8 [Response COM1]/ T4 enex_3 tm(Tdmt)[NoResponse]/ T18 Retry_9

[Retry =3]/ T5 enex_4

1248 1249 1250 1251 Figure 33 Submachine to establish communication Table 36 shows the state transition tables of the Master DL-mode handler. Table 36 State transition tables of the Master DL-mode handler
STATE NAME Idle_0 EstablishComm_1 Startup_2 Preoperate_3 Operate_4 SM: WURQ_5 SM: ComRequestCOM3_6 SM: ComRequestCOM2_7 SM: ComRequestCOM1_8 SM: Retry_9 TRANSITION T1 SOURCE STATE 0 STATE DESCRIPTION Waiting on wakeup request: DL_SetMode (STARTUP) Perform wakeup procedure (submachine) System management uses this state for Device identification, check, and communication configuration On-request data (parameter, commands, events) exchange without process data Process data exchange and on-request data (parameter, commands, events) exchange Create wakeup current pulse (5.3.3.3). Wait T DMT (Table 34). Try test message with COM3 transmission rate with the help of the frame handler. Wait T DMT (Table 34). Try test message with COM2 transmission rate with the help of the frame handler. Wait T DMT (Table 34). Try test message with COM1 transmission rate with the help of the frame handler. Wait T DMT (Table 34). Check number of retries TARGET STATE 1 ACTION Activate frame handler. Retry = 0.

1252

Working Draft
TRANSITION T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 SOURCE STATE 1 1 1 1 2 3 3 3 3 2 TARGET STATE 2 2 2 0 3 2 0 0 4 4

70
ACTION

61131-9/WD V0.5 IEC

Activate command handler. Return DL_Mode.ind(STARTUP) and DL_Mode.ind(COM3). Comment: COM3 established. Activate command handler. Return DL_Mode.ind(STARTUP) and DL_Mode.ind(COM2). Comment: COM2 established. Activate command handler. Return DL_Mode.ind(STARTUP) and DL_Mode.ind(COM1). Comment: COM1 established. Deactivate frame handler. Return DL_Mode.ind(STOP). Activate on-request data, service, and event handler. Send MasterCommand ("DevicePreoperate"), Return DL_Mode.ind(PREOPERATE). Deactivate on-request data, service, command, and event handler. Send MasterCommand("DeviceStartup"), Return DL_Mode.ind(STARTUP). Send MasterCommand ("Fallback"), deactivate all handlers. Return DL_Mode.ind(INACTIVE). Deactivate all handlers. Return DL_Mode.ind(COMMLOSS). Activate process data handler. Send MasterCommand("ProcessDataOutputOperate"), Return DL_Mode.ind(OPERATE). Activate process data handler. Activate on-request data, service, and event handler. Send MasterCommand("ProcessDataOutputOperate"). Return DL_Mode.ind(OPERATE). Deactivate process data, on-request data, service, and event handler. Send MasterCommand("DeviceStartup"). Return DL_Mode.ind(STARTUP). Send MasterCommand ("Fallback"), Deactivate all handlers. Return DL_Mode.ind(INACTIVE). Deactivate all handlers. Return DL_Mode.ind(COMMLOSS). Set transmission rate COM3. Set transmission rate COM2. Set transmission rate COM1. Increment Retry TYPE DEFINITION No valid Device message received Number of retries to establish communication

T12 T13 T14 T15 T16 T17 T18

4 4 4 5 6 7 8 9

2 0 0 6 7 8 9 5

1253

T19

INTERNAL ITEMS NoResponse Retry

Bool Variable

1254 1255 1256 1257 1258 7.3.2.5 Device state machine of the DL-mode handler

Figure 34 shows the Device state machine of the DL-mode handler. The states 3 and 4 provide no explicit functionality, but show different availabilities of subsidiary state machines.

61131-9/WD V0.5 IEC

71

Working Draft

/Initialization DL_Mode_INACTIVE/ T8 DL_Mode_INACTIVE/ T9 Idle_0

tm(Tdsio)/ T10

DL_Mode_STARTUP/ T1 EstablishCom_1

ComTrig/ T2 Startup_2

FHInfo_ILLEGAL_FRAMETYPE/ T11

FHInfo_ILLEGAL_FRAMETYPE/ T12

MC_STARTUP/ T7 MC_OPERATE/ T5

MC_STARTUP/ T6 PreOperate_3

MC_PREOPERATE/ T3 Operate_4 MC_OPERATE/ T4

1259 1260 1261 1262 Figure 34 Device state machine of the DL-mode handler Table 37 shows the state transition tables of the Device DL-mode handler. Table 37 State transition tables of the Device DL-mode handler
STATE NAME Idle_0 EstablishComm_1 Startup_2 Preoperate_3 STATE DESCRIPTION Waiting on wakeup current pulse (PL_WakeUp.ind). Frame handler activated and waiting for the next transmission Compatibility check (see 9.2.3.3) On-request data (parameter, commands, events) exchange without process data Process data exchange and on-request data (parameter, commands, events) exchange SOURCE STATE 0 1 2 3 2 3 4 3 4 1 TARGET STATE 1 2 3 4 4 2 2 0 0 0 Activate frame handler. Activate command handler. Cast DL_Mode.ind(STARTUP). Activate on-request data, service, and event handler. Cast DL_Mode.ind(PREOPERATE). Activate process data handler. Cast DL_Mode.ind(OPERATE). Activate process data handler. Activate on-request data, service, and event handler. Cast DL_Mode.ind(OPERATE). Deactivate on-request data, service, and event handler. Cast DL_Mode.ind(STARTUP). Deactivate process data handler. Deactivate on-request data, service, and event handler. Cast DL_Mode.ind(STARTUP). Wait until T FBD elapsed, then deactivate all handlers and return DL_Mode.ind(INACTIVE). Wait until T FBD elapsed, then deactivate all handlers and return DL_Mode.ind(INACTIVE). Deactivate frame handler. Return DL_Mode.ind(INACTIVE). ACTION

1263

Operate_4 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10

Working Draft
TRANSITION T11 T12 SOURCE STATE 4 3 TARGET STATE 2 2 TYPE Time Variable

72
ACTION

61131-9/WD V0.5 IEC

Deactivate process data handler. Deactivate on-request data, service, and event handler. Cast DL_Mode.ind(STARTUP). Deactivate on-request data, service, and event handler. Cast DL_Mode.ind(STARTUP). DEFINITION See Table 35. Decoded MasterCommand (see Figure 50, state "CommandHandler_2")

1264
INTERNAL ITEMS T FBD MC_xxxx

1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 7.3.3 7.3.3.1 Frame handler General

The general role of the frame handler has been described in 7.1 and 7.2.2.1. This subclause specifies the structure and types of F-sequences, and the behaviour (dynamics) of the frame handler. 7.3.3.2 F-sequences

A Master and its Device exchange data by means of frames. An F-sequence comprises a message of the Master followed by a message of the Device as shown in Figure 35. Each message consists of UART frames.
F-sequence ("frame sequence")
Master message (frame)

UART frame

UART frame

...

UART frame

Device message (frame)

F-sequence type

UART frame

...

UART frame

1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 Figure 35 SDCI F-sequences The Master message starts with the "F-sequence Control" (FC) octet, followed by the "CHECK/TYPE" (CKT) octet, and optionally followed by either "Process Data" (PD) and/or "On-request Data" (OD) octets. The Device message in turn starts optionally with "Process Data" (PD) octets and/or "On-request Data" (OD) octets, followed by the "CHECK/STAT" (CKS) octet. Various F-sequence types can be selected to meet the particular needs of an actuator or sensor (scan rate, amount of process data). The length of Master and Device messages may vary depending on the type of messages and the data transmission direction, see Figure 35. Figure 36 presents an overview of the defined F-sequence types. Parts within dotted lines depend on the read or write direction within the F-sequence control octet.

61131-9/WD V0.5 IEC 1287 1288 1289 1290 1291 1292 1293 1294

73

Working Draft

The fixed F-sequence types consist of TYPE_0, TYPE_1_1, TYPE_1_2, and TYPE_2_1 through TYPE_2_6. The variable F-sequence types consist of TYPE_1_V and TYPE_2_V. The different F-sequence types meet the various requirements of sensors and actuators regarding their process data width and respective conditions. See A.2 for details of Fsequence types. See A.3 for the timing constraints with F-sequences. As a general rule, all the octets of data types > 1 octet are "big endian" coded for transmission, i.e. the most significant octet (MSO) is sent first, followed by the least significant octet (LSO) as shown in Figure 1.
TYPE_0
FC CKT RD WR OD CKS

TYPE_1_1

FC

CKT

PD0

PD1

CKS

TYPE_1_2

FC

CKT

OD0

OD1

CKS

TYPE_1_V

FC

CKT

OD0

ODn

CKS

TYPE_2_1

FC

CKT

OD

PD

CKS

TYPE_2_2

FC

CKT

OD

PD0

PD1

CKS

TYPE_2_3

FC

CKT

PD

OD

CKS

TYPE_2_4

FC

CKT

PD0

PD1

OD

CKS

TYPE_2_5

FC

CKT

PD

OD

PD

CKS

TYPE_2_6

FC

CKT

PD0

PD1

OD

PD0

PD1

CKS

TYPE_2_V

FC

CKT

PD0

PDn-1

1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 7.3.3.3

OD0

ODm-1

PD0

PDk-1

CKS

Figure 36 Overview of F-sequence types MasterCycleTime constraints

Upon completion of startup a Device is able to communicate. In order to detect the disconnecting of Devices it is highly recommended for the Master to perform from this point on a periodic communication ("keep-alive message") via acyclic F-sequences by the data link layer. The minimum cycle times specified in A.2.6 shall be considered. After this phase, cyclic process data communication can be started by the Master via the DL_SetMode(OPERATE) service. F-sequence types for the cyclic data exchange shall be used in this communication phase to address a Device.

Working Draft 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319

74

61131-9/WD V0.5 IEC

The Master shall use the time indicated in the parameter MasterCycleTime (Table B.1) after sending the MasterCommand "DeviceOperate" ( Table B.2) for the first time. The tolerance of this time shall be within 0 % to +10 % (including jitter). In cases, where a Device has to be switched back to SIO mode after parameterization, the Master shall send a command "Fallback" (Table B.2) followed by a confirmation of the Device. 7.3.3.4 Master state machine of the frame handler

Figure 37 shows the Master state machine of the frame handler. Two submachines describing reactions on communication errors are shown in Figure 38 and Figure 39. The frame handler takes care of the special communication requirements within the states "EstablishCom", "Startup", "PreOperate", and "Operate" of the DL-Mode handler. A special FH_Config(COMREQUEST) command in state "Inactive_0" causes the frame handler to send "test" messages with F-sequence TYPE_0 and different transmission rates during the establish communication sequence. The state "StartupPreop_2" is the checkpoint for all On-request Data activities such as ISDUs, parameters, commands, and events.
FH_Config_OPERATE/ T1

FH_Config_INACTIVE/ T27

FH_Config_INACTIVE/ T26 Inactive_0

/Initialization

Operate_8

FH_Config_OPERATE/ T15 StartupPreop_2

FH_Config_STARTUP/ T6

tm(Tcyc)/ T16

[Ready]/ T14 tm(Tinitcyc)/ T7 SetOD_7 GetOD_3

FH_Config_COMREQUEST/ T2 tm(TF-sequence)/ T4 AwaitReply_1 [ReceivedOK]/ T3 [ReadyToSend]/ T8 Response_4 [ReceivedNotOK]/ T5 [Retry = MaxRetry]/ T13 enex_1

GetPD_9

[Ready]/ T17

GetOD_10

[ReadyToSend]/ T18 Response_11

[ReceivedOK]/ T12 enex_2

enex_3 enex_4 [ReceivedOK]/ T22 SetPD_14

[Retry = MaxRetry]/ T23

[Ready]/ T24 [NoError]/ T25 SetOD_15

1320 1321 1322 1323 Figure 37 Master state machine of the frame handler The state "Operate_8" is the checkpoint for cyclic process data exchange. Depending on the F-sequence type the frame handler generates Master messages with Process Data acquired

61131-9/WD V0.5 IEC 1324 1325 1326

75

Working Draft

from the Process Data handler and optionally On-request Data acquired from the on-request data handler. Figure 38 shows the submachine of state "Response 4".
Response_4

/T8 enex_2 AwaitReply_5 tm(TF-sequence)/ T9 enex_1 Errorhandling_6 /T13

/T12

[ReceivedNotOK]/ T10 tm(Tinitcyc)[Retry < MaxRetry]/ T11 (Re-send)

1327 1328 1329 Figure 38 Submachine "Response 4" of the frame handler Figure 39 shows the submachine of state "Response 11".
Response_11

/T18 AwaitReply_12

tm(TF-sequence)/ T19 ErrorHandling_13 [ReceivedNotOK]/ T20

/T23 enex_3

/T22

tm(Tcyc)[Retry < MaxRetry]/ T21 (Re-send)

1330 1331 1332 1333 1334

Inactive_0 AwaitReply_1 StartupPreop_2 GetOD_3 Response_4 SM: AwaitReply_5 SM: ErrorHandling_6 SetOD_7 Operate_8 GetPD_9 GetOD_10

enex_4

Figure 39 Submachine "Response 11" of the frame handler Table 38 shows the state transition tables of the Master frame handler. Table 38 State transition table of the Master frame handler
STATE NAME STATE DESCRIPTION Waiting on ComRequest or Startup Waiting on ComRequest response Checkpoint: Wait until T initcyc from last cycle elapsed Collect on-request data from on-request handler (ISDU, parameter/command, event) Device response and error check Waiting on Device response Error check and reaction (retry, etc.) Distribute on-request data Checkpoint: Wait until T cyc from last cycle elapsed Collect process data from PD handler Collect on-request data from on-request handler (ISDU, parameter/command, event)

Working Draft
STATE NAME Response_11 SM: AwaitReply_12 SM: ErrorHandling_13 SetPD_14

76
STATE DESCRIPTION Device response and error check Waiting on Device response Error check and reaction (Retry, etc.) Distribute process data Distribute on-request data

61131-9/WD V0.5 IEC

1335

SetOD_15 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 SOURCE STATE 0 0 1 1 1 0 2 3 5 5 6 4 4 7 2 8 9 10 12 12 13 11 11 14 15 2 8

TARGET STATE 8 1 0 0 0 2 3 4 6 6 5 7 0 2 8 9 10 11 13 13 12 14 0 15 8 0 0 TYPE Variable Number Bool Bool Timer Time Time Retry counter MaxRetry = 2, see Table 91 -

ACTION

Read octet 3 (MinCycleTime) in direct parameter page with F-sequence TYPE_0 Return value of MinCycleTime Timeout: negative response Other error: negative response Cast ComTrig to on-request handler Create message from CMD.req and send it to Device. Start F-sequence LengthTimer Re-send message Error indication: FHInfo.ind(COMMLOST) Cast PDTrig to process data handler Cast ComTrig to on-request handler Create message from CMD.req and PD.req and send it to Device Re-send message Error indication: FHInfo.ind(COMMLOST) Stop communication Stop communication DEFINITION

1336

T27

INTERNAL ITEMS Retry MaxRetry ReceivedOK ReceivedNotOK F-sequence LengthTimer t F-sequence t cyc

Error checking of Device message successful Error checking of Device message not successful due to detected errors Measurement of Device response time See equation (A.6) See equation (A.7)

61131-9/WD V0.5 IEC

INTERNAL ITEMS t initcyc TYPE Time See A.2.6

77
DEFINITION

Working Draft

1337 1338 1339 7.3.3.5 Device state machine of the frame handler

Figure 40 shows the Device state machine of the frame handler.

[Ready]/ T6 (send) CreateMessage_4

tm(ComTimeout)/ T9 Idle_1 FH_Config_ACTIVE/ T1 FH_Config_INACTIVE/ T10

/Initialization

Inactive_0

[No error]/ T5

[Error]/ T7

[FirstOctet]/ T2

tm(MessageTimeout)/ T8

CheckMessage_3 [Completed]/ T4

GetMessage_2 [NextOctet]/ T3

1340 1341 1342 1343 Figure 40 Device state machine of the frame handler Table 39 shows the state transition tables of the Device frame handler. Table 39 State transition tables of the Device frame handler
STATE NAME Inactive_0 Idle_1 GetMessage_2 CheckMessage_3 Waiting for activation Waiting on first octet of Master message Receive Master message octet by octet Check F-sequence type, checksum, length, consistency Create message from CMD.rsp, PD.rsp, EventFlag State and PD Valid State TARGET STATE 1 2 2 3 4 1 1 Start message timer Check message length Stop message timer Create CMD.ind and/or PD.ind Create PL_Transfer.rsp Indicate error via FHInfo(ILLEGAL_FRAME_TYPE) only in case of a detected illegal F-sequence type. No indication of other errors e.g. CHECKSUM_MISMATCH. Create FHInfo.ind(COMMLOST). Actuators shall observe this information and take corresponding actions. TYPE Time DEFINITION Observation of the message transmission time for the purpose of resynchronization of communication ("first octet detection") ACTION STATE DESCRIPTION

1344

CreateMessage_4 TRANSITION T1 T2 T3 T4 T5 T6 T7 SOURCE STATE 0 1 2 2 3 4 3

T8 T9 T10

2 1 1

1 1 0

1345

INTERNAL ITEMS MessageTimeout

Working Draft
INTERNAL ITEMS ComTimeout MessageTimeout FirstOctet NextOctet Error TYPE Time Time Service Service Bool

78
DEFINITION

61131-9/WD V0.5 IEC

Observation of the Device specific maximum cycle time. This is important especially for actuators. See 10.2. Maximum "length" of Master message of the actual F-sequence type PL_Transfer.ind with the first octet of the Master message PL_Transfer.ind with subsequent octets of the Master message One of the possible errors detected: ILLEGAL_FRAME_TYPE, CHECKSUM_MISMATCH

1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 7.3.4 7.3.4.1 Process data handler General

The transport of process data for output data is performed using the DL_OutputUpdate services and for input data using the DL_InputTransport services (Figure 25). A process data cycle is completed when the whole set of process data has been transferred between Master and Device. Such a cycle can last for more than one F-sequence. All process data are transmitted within one F-sequence when using F-sequences of TYPE_2_x (Figure 36). In this case the execution time of a process data cycle is equal to the cycle time (see Figure 41). 7.3.4.2 Interleave mode

All Process Data and On-request Data are transmitted with multiple alternating F-sequences TYPE_1_1 (process data) and TYPE_1_2 (on-request data) as shown in Figure 41. It illustrates the Master messages writing output process data to a Device. Within a process data cycle all input data shall be read first followed by all output data to be written. A process data cycle comprises all cycle times required to transmit the complete process data.

FC FC FC

CKT CKT CKT CKT

PD0 OD0 PD2 OD0

PD1 OD1 PD3 OD1

Cycle time

Process data cycle n

FC

FC FC

CKT CKT CKT CKT

PDx-1 OD0 PD0 OD0

PDx OD1 PD1 OD1 Not recommended for new developments of Devices

Process data cycle n+1

FC FC

1362 1363 1364 1365

t (time)

Figure 41 Interleave mode for the segmented transmission of process data 7.3.4.3 Master state machine of the process data handler

Figure 42 shows the Master state machine of the process data handler.

61131-9/WD V0.5 IEC

79

Working Draft

/initialization Inactive_0

PDComTrig/ T1

PD_Config_INACTIVE/ T9

PD_Config_INACTIVE/ T11 PD_Config_INACTIVE/ T10

PD_Config_SINGLE/ T2

PD_Config_INTERLEAVE/ T4

PDSingle_1

PDInInterleave_2

[Input Data Completed]/ T6

PDOutInterleave_3

[Output Data Completed]/ T8 PDComTrig/ T3 PDComTrig/ T5 PDComTrig/ T7

1366 1367 1368 1369

Figure 42 Master state machine of the process data handler Table 40 shows the state transition tables of the Master process data handler. Table 40 State transition tables of the Master process data handler
STATE NAME Inactive_0 PDSingle_1 PDInInterleave_2 Waiting for activation Process data communication via single F-sequences Input ProcessDataIn interleave mode Output ProcessDataOut interleave mode TARGET STATE 0 1 1 2 2 3 3 2 0 0 0 TYPE ACTION Create PD.req with no process data Create DL_PDInputTransport.ind, DL_PDCycle.ind and PD.req with input and output data Create PD.req for input data Create DL_PDInputTransport.ind (see 7.2.1.11) Create PD.req with output data Create DL_PDCycle.ind (see 7.2.1.12) DEFINITION STATE DESCRIPTION

1370

PDOutInterleave_3 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 SOURCE STATE 0 0 1 0 2 2 3 3 1 2 3

1371

T11

INTERNAL ITEMS None

1372 1373 1374 7.3.4.4 Device state machine of the process data handler

Figure 43 shows the Device state machine of the process data handler.

Working Draft

80

61131-9/WD V0.5 IEC

/initialization PDTrig/ T1 Inactive_0

PD_Config_ACTIVE/ T2 PDSingle_1

PD_Config_INACTIVE/ T7 PDTrig/ T3 [PD incomplete]/ T4 [New output complete]/ T5 [Cycle complete]/ T6

HandlePD_2

1375 1376 1377 1378 Figure 43 Device state machine of the process data handler Table 41 shows the state transition tables of the Device process data handler. Table 41 State transition tables of the Device process data handler
STATE NAME Inactive_0 PDActive_1 Waiting on activation Handler active and waiting on next message Check process data for completeness SOURCE STATE 0 0 1 2 2 2 1 TARGET STATE 0 1 2 1 1 1 0 TYPE Ignore Process Data Create PD.ind with Process Data (see 7.2.2.3) Create DL_PDOutputTransport.ind (see 7.2.1.9) Create DL_PDCycle.ind (see 7.2.1.12) DEFINITION ACTION STATE DESCRIPTION

1379

HandlePD_2 TRANSITION T1 T2 T3 T4 T5 T6

1380
None

T7

INTERNAL ITEMS

1381 1382 1383 1384 1385 1386 1387 1388 1389 7.3.5 7.3.5.1 On-request data handler General for Master and Device

The Master on-request data handler is a subordinate state machine active in the "Operate_4" state of the DL-mode handler (Figure 32). It controls 3 other state machines, the so-called service handler, the control handler, and the event handler. It always starts with the service handler first. Whenever an EventFlag.ind is received, the state machine will switch to the event handler. After the complete readout of the event information it will return to the service handler state.

61131-9/WD V0.5 IEC 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409

81

Working Draft

Whenever a Control.req is received while in the service handler or in the event handler, the state machine will switch to the control handler. Once the control request has been served, the state machine will return to the previously active state. The Device on-request data handler obtains information on the communication channel and the memory address via the Cmd.req service. The communication channels are totally independent. In case of a valid access, the corresponding service, control or event state machine is addressed on the relevant communication channel. The Device shall respond to read requests to not implemented address ranges with the value "0". It shall ignore write requests to not implemented address ranges. Requests for access sent in F-sequence types without addressing on the process communication channel shall also be ignored. In case of an ISDU page access in a Device without ISDU support, the Device shall respond with NO_SERVICE. An error message is not created.
NOTE Cmd.ind (R, ISDU, FlowCTRL = IDLE) is the default message if there are no on-request data pending for transmission.

7.3.5.2

Master state machine of the on-request data handler

Figure 44 shows the Master state machine of the on-request data handler. The on-request handler casts the ComTrig.ind for the next message content to the currently active subsidiary handler (service, command, or event).

/initialization Inactive_0

OH_Config_ACTIVE/ T1

OH_Config_INACTIVE/ T16

ComTrig/ T12

Startup_1

OH_Config_STARTUP/ T14 OH_Config_STARTUP/ T13 [Startup completed]/ T2

OH_Config_STARTUP/ T15

ComTrig/ T11 Service_2

[Done & No EventActive]/ T4 Command_3

DL_Control/ T3 DL_Control/ T7

EventFlag/ T5

[Done]/ T6 Event_4

ComTrig/ T9

[Done & EventActive]/ T8

ComTrig/ T10

1410 1411 Figure 44 Master state machine of the on-request data handler

Working Draft 1412 1413 1414 1415

82

61131-9/WD V0.5 IEC

This is performed through one of the ControlComTrig, EventComTrig or ServiceComTrig services. Table 42 shows the state transition tables of the Master process data handler. Table 42 State transition tables of the Master on-request data handler
STATE NAME Inactive_0 Startup_1 Waiting on activation System management uses this state for Device identification, check, and communication configuration while reading and writing the Direct Parameter page with F-sequence TYPE_0 (see Figure 4 and A.2.2). Default state of the on-request handler (lowest priority) State to control the Device via commands with highest priority State to convey event information (errors, warnings, notifications) with higher priority SOURCE STATE 0 1 2 3 2 4 4 3 3 4 2 1 2 3 4 0 TARGET STATE 1 2 3 2 4 2 3 4 3 4 2 1 1 1 1 4 TYPE EventActive = TRUE EventActive = FALSE Cast ControlComTrig.ind (Figure 49) Cast EventComTrig.ind (Figure 51) Cast ISDUComTrig.ind (Figure 47) Read or write direct parameter page via CMD.req DEFINITION Flag to indicate return direction after interruption of event processing by a high priority command request ACTION STATE DESCRIPTION

Service_2 Command_3

1416

Event_4 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15

1417

T16

INTERNAL ITEMS EventActive

1418 1419 1420 7.3.5.3 Device state machine of the on-request data handler

Figure 45 shows the Device state machine of the on-request data handler.

61131-9/WD V0.5 IEC

83
EventRequest/ T5

Working Draft

/initialization

CommandRequest/ T2

Idle_1

OH_Config_ACTIVE/ T1 OH_Config_INACTIVE/ T6

Inactive_0

ParameterRequest/ T3

SPDURequest/ T4

1421 1422 1423 1424 Figure 45 Device state machine of the on-request data handler Table 43 shows the state transition tables of the Device on-request data handler. Table 43 State transition tables of the Device on-request data handler
STATE NAME Inactive_0 Waiting on activation Waiting on messages with on-request data. Decomposition and analysis. SOURCE STATE 0 1 1 TARGET STATE 1 1 1 Trigger command handler Trigger service handler (direct parameter page). If DL-Mode = STARTUP then cast DL_Read / DL_Write, otherwise cast DL_ReadParam / DL_WriteParam Trigger service handler (ISDU) Trigger event handler TYPE Service Service Service Service DEFINITION CMD.ind(W, PARAMETER, 0, Command) CMD.ind(R/W, PARAMETER, <> 0, Data) CMD.ind(R/W, ISDU, FlowCtrl, Data) CMD.ind(R/W, EVENT, n, Data) ACTION STATE DESCRIPTION

1425

Idle_1 TRANSITION T1 T2 T3

T4 T5

1 1 1

1 1 0

1426

T6

INTERNAL ITEMS CommandRequest ParameterRequest ISDURequest EventRequest

1427 1428 1429 1430 1431 1432 1433 1434 7.3.6 7.3.6.1 Service handler Indexed Service Data Unit (ISDU)

The general structure of an ISDU is illustrated in Figure 46 and described in detail in A.5. The sequence of the elements corresponds to the transmission sequence. The elements of an ISDU can take various forms depending on the type of service. The ISDU allows accessing data objects (parameters and commands) to be transmitted (Figure 4). The data objects shall be addressed by the Index element.

Working Draft

84
Service Length

61131-9/WD V0.5 IEC

ExtLength Index Subindex Data 1 ... Data n CHKPDU = Checksum

1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447
FlowCTRL 0x00 to 0x0F COUNT

Figure 46 Structure of the ISDU 7.3.6.2 Transmission of ISDUs

An ISDU is transmitted via the ISDU communication channel (see Figure 6 and A.1.2). A number of messages are typically required to perform this transmission (segmentation). The Master transfers an ISDU by sending a service request to the Device via the ISDU communication channel. It then receives the Devices response via the same channel. In the ISDU communication channel the "Address" element within the F-sequence control octet accommodates a counter (= FlowCTRL). FlowCTRL is controlling the segmented data flow (A.1.2) by counting the frames of the ISDU (modulo 16) during transmission. The Master uses the "Length" element of the ISDU and FlowCTRL to check the accomplishment of the complete transmission. Permissible values for FlowCTRL are defined in Table 44. Table 44 FlowCTRL definitions
Definition

Frame counter within an ISDU. Increments beginning with 1 following start with START. Jumps back from 15 to 0 in the event of an overflow. 0x10 START Start of an ISDU, i.e., start of a request or a response. For the start of a request, any previously incomplete services may be rejected. For a start request associated with a response, a Device shall send No Service until its application returns response data. 0x11 IDLE 1 No request for ISDU transmission. 0x12 IDLE 2: Reserved for future use (see NOTE) No request for ISDU transmission. 0x13 to 0x1E 0x1F Reserved (see NOTE) ABORT (see NOTE) Abort entire service. The Master responds by rejecting received response data. The Device responds by rejecting received request data and may generate an abort. NOTE In state ISDUIdle_1 these values shall not lead to a communication error.

61131-9/WD V0.5 IEC 1448 1449 7.3.6.3

85

Working Draft

Master state machine of the service handler

Figure 47 shows the Master state machine of the service handler.

/Initialization Inactive_0

SH_Config_ACTIVE/ T1 ISDUComTrig[ ParaRequest]/ T13

SH_Config_INACTIVE/ T16 ISDUComTrig[ DL_ISDUTransport]/ T2

Idle_1

ISDURequest_2 [Data written]/ T4

ISDUComTrig/ T14

DL_Mode_COMLOSS/ T12

ISDUComTrig/ T3

ISDUComTrig/ T5

ISDUComTrig/ T11 ISDUError_4 SH_Config_STOP/ T15 [Error]/ T10 ISDUComTrig[ Transmission completed]/ T8

[Error]/ T9

ISDUWait_3

[ResponseStart]/ T6

ISDUResponse_5 ISDUComTrig/ T7

1450 1451 1452 1453 Figure 47 Master state machine of the service handler Table 45 shows the state transition tables of the Master service handler. Table 45 State transition tables of the Master service handler
STATE NAME Inactive_0 Idle_1 ISDURequest_2 ISDUWait_3 ISDUError_4 Waiting on activation Waiting on transmission of next on-request data Transmission of ISDU request data Waiting on response from Device. Observe ISDUTimer Error handling after detected errors Get response data from Device TARGET STATE 1 2 2 3 3 5 5 Cast CMD.req with ISDU write start condition [CMD.req (W, ISDU, flowCtrl = START, data)] Cast CMD.req with ISDU data write and FlowCTRL under conditions of Table 44 Start ISDUTimer Cast CMD.req with ISDU read start condition [CMD.req (R, ISDU, flowCtrl = START)] Stop ISDUTimer Cast CMD.req with ISDU data read and FlowCTRL under conditions of ACTION STATE DESCRIPTION

1454

ISDUResponse_5 TRANSITION T1 T2 T3 T4 T5 T6 T7 SOURCE STATE 0 1 2 2 3 3 5

Working Draft
TRANSITION SOURCE STATE TARGET STATE Table 44 T8 T9 T10 T11 T12 T13 T14 T15 5 3 5 4 2 1 1 4 1 1 4 4 1 4 1 1 1 0 TYPE Variable Service Service Variable

86
ACTION

61131-9/WD V0.5 IEC

Cast positive DL_ ISDUTransport confirmation Cast CMD.req with ISDU abortion [CMD.req (R, ISDU, flowCtrl = ABORT)]. Cast negative DL_ ISDUTransport confirmation Cast DL_CMD.req with appropriate data, cast positive DL_Read/WritePara confirmation Cast CMD.req with idle message [CMD.req (R, ISDU, flowCtrl = IDLE)] DEFINITION Measurement of Device response time (watchdog, Table 91) CMD.cnf(data <> ISDU_BUSY) DL_Read or DL_Write Any detectable error within the ISDU transmission or DL_SDPUAbort requests, or any violation of the ISDU acknowledgement time (Table 91)

1455

T16

INTERNAL ITEMS ISDUTimer ResponseStart ParaRequest Error

1456 1457 1458 7.3.6.4 Device state machine of the service handler

Figure 48 shows the Master state machine of the service handler.

/Initialization SH_Config_ACTIVE/ T1 ISDUStart/ T2

ISDUWrite/ T3

Inactive_0

ISDUIdle_1

ISDURequest_2

SH_Config_INACTIVE/ T12 ISDUAbort/ T11 ISDUResponse_4

ISDUAbort/ T9 ISDUAbort/ T10 ISDUWait_3 ISDURespStart/ T6 ISDURead/ T7 ISDURead/ T5 [ISDURecComplete]/ T4

[ISDUSendComplete]/ T8

1459 1460 1461 1462 Figure 48 Device state machine of the service handler Table 46 shows the state transition tables of the Device service handler. Table 46 State transition tables of the Device service handler
STATE NAME Inactive_0 ISDUIdle_1 ISDURequest_2 Waiting on activation Waiting on next ISDU transmission Reception of ISDU request STATE DESCRIPTION

61131-9/WD V0.5 IEC

STATE NAME ISDUWait_3

87
STATE DESCRIPTION

Working Draft

Waiting on data from application layer to transmit (see DL_ISDUTransport) Transmission of ISDU response data TARGET STATE 1 2 2 3 3 4 4 1 1 1 1 0 TYPE Service Service Service Service Service Service Service CMD.ind(W, ISDU, Start, Data) CMD.ind(W, ISDU, FlowCtrl, Data) CMD.ind(R, ISDU, Start, ...) DL_ ISDUTransport.rsp() CMD.ind(R, ISDU, Start or FlowCtrl, ...) CMD.ind(R, ISDU, IDLE, ...) CMD.ind(R/W, ISDU, Abort, ...) Start receiving of ISDU request data Receive ISDU request data Cast DL_ ISDUTransport.ind to application layer (see DL_ ISDUTransport) Cast CMD.rsp with "busy" indication (Table A.14) Cast CMD.rsp with ISDU response data Cast DL_ ISDUAbort Cast DL_ ISDUAbort DEFINITION ACTION

1463

ISDUResponse_4 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 SOURCE STATE 0 1 2 2 3 3 4 4 2 3 4 1

1464

T12

INTERNAL ITEMS ISDUStart ISDUWrite ISDURecComplete ISDURespStart ISDURead ISDUSendComplete ISDUAbort

1465 1466 1467 1468 1469 1470 1471

Control code PDOutValid PDOutInvalid

7.3.7 7.3.7.1

Command handler General

The command handler passes the control code contained in Control.req to the cyclically operating frame handler by sending CMD.req via the page communication channel. The permissible control codes are listed in Table 47. Table 47 Control codes
MasterCommand ProcessDataOutputOperate DeviceOperate Description Process output data valid Process output data invalid or missing

1472 1473 1474 7.3.7.2 Master state machine of the command handler

Figure 49 shows the Master state machine of the command handler.

Working Draft

88

61131-9/WD V0.5 IEC

/Initialization Inactive_0

CH_Config_ACTIVE/ T1 DL_Control_PDVALID/ T2

CH_Config_INACTIVE/ T6 DL_Write_MasterCmd/ T4

Idle_1

MasterCommand_2

DL_Control_PDINVALID/ T3

ControlComTrig/ T5

1475 1476 1477 1478 Figure 49 Master state machine of the command handler Table 48 shows the state transition tables of the Master command handler. Table 48 State transition tables of the Master command handler
STATE NAME Inactive_0 Idle_1 Waiting on activation Waiting on new command Waiting on transmission of command TARGET STATE 1 1 1 2 1 0 TYPE Service Cast DL_Control.ind(PDVALID) to signal valid ProcessDataIn Cast DL_Control.ind(PDINVALID) to signal invalid ProcessDataIn Transmission of MasterCommand DEFINITION DL_Write(0, MasterCommand), see Table B.2. ACTION STATE DESCRIPTION

1479

MasterCommand_2 TRANSITION T1 T2 T3 T4 T5 SOURCE STATE 0 1 1 1 2 1

1480

T6

INTERNAL ITEMS DL_Write_MasterCmd

1481 1482 1483 7.3.7.3 Device state machine of the command handler

Figure 50 shows the Device state machine of the control handler.

DL_Control_VALID/ T2 CH_Config_ACTIVE/ T1 DL_Write_MasterCmd/ T4

/Initialization

Inactive_0

Idle_1

CommandHandler_2

CH_Config_INACTIVE/ T6 DL_Control_INVALID/ T3

[Done]/ T5

1484 1485

Figure 50 Device state machine of the command handler

61131-9/WD V0.5 IEC 1486 1487

89

Working Draft

Table 49 shows the state transition tables of the Device command handler. Table 49 State transition tables of the Device command handler
STATE NAME Inactive_0 Idle_1 Waiting on activation Waiting on next MasterCommand Decompose MasterCommand and cast specific actions (see B.1.2) TARGET STATE 1 1 1 2 1 0 TYPE Service Cast PD-Valid(PDIN_VALID) to signal process data state to frame handler Cast PD-Valid(PDIN_INVALID) to signal process data state to frame handler DEFINITION CMD.ind(W, PARAMETER, 0, MasterCommand), see Table B.2 ACTION STATE DESCRIPTION

1488

CommandHandler_2 TRANSITION T1 T2 T3 T4 T5 SOURCE STATE 0 1 1 1 2 1

1489

T6

INTERNAL ITEMS DL_Write_MasterCmd

1490 1491 1492 1493 1494 1495 1496 1497 1498

Address Parameter Name

7.3.8 7.3.8.1

Event handler Events

The general structure and coding of events is described in A.6. There are two types of events, one without details, which is not recommended for new developments, and another one with details. Event codes without details are listed in Table A.16. Event codes with details can be found in Annex D. The structure of the event buffer for event codes with details within a Device is illustrated in Table 50. Table 50 Event buffer
Description

0x00 0x01 0x02 0x03 0x04 0x05 0x06

StatusCode EventQualifier 1 EventCode 1

Summary of status and error information. Also used to control read access for individual messages. Type, mode and source of the first event 16-bit event code of the first event

EventQualifier 2 EventCode 2

Type, mode and source of the second event 16-bit event code of the second event

0x10 0x11 0x12 0x13 0x1F Reserved for future use EventQualifier 6 EventCode 6 Type, mode and source of the sixth event 16-bit event code of the sixth event

1499

Working Draft 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 7.3.8.2 Event processing

90

61131-9/WD V0.5 IEC

The Device AL writes an event to the event buffer and then sets the event flag, which is sent to the Master in the next frame in the CKS octet ( 7.3.3.2 and A.1.5). If the event flag is set, the Master shall switch from the service handler to the event handler. The event handler starts reading the status code. Once the status code has been read, the Device shall not modify the activated events within the event buffer (Table 50). It may write data to the free fields in the event buffer, but not modify the status code. If the event detail bit is set (Figure A.23), the Master shall read the event details of the events indicated in the status code from the event buffer. Once it has read an event detail, it shall generate a DL event indication. After reception of DL_EventConf, the Master shall write any data to the status code to reset the event flag. The event handling on the Master shall be completed regardless of the contents of the event data received (event qualifier, event code). If the Event detail bit is not set (Figure A.22) the Master Event handler shall generate the standardized Events according Table A.16 beginning with the most significant bit in the EventCode. Write access to the status code indicates the end of event processing to the Device. The Device then resets the event flag and may now change the content of the fields in the event buffer. The Device shall not evaluate the content of the written Master data. 7.3.8.3 Master state machine of the event handler

Figure 51 shows the Master state machine of the event handler.

/Initialization

DL_Mode_COMLOSS/ T10 EH_Config_ACTIVE/ T1 DL_EventConf/ T8

Inactive_0

DL_Mode_COMLOSS/ T7

EH_Config_INACTIVE/ T9

EventComTrig/ T3

EventConfirmation_4

Idle_1

EventComTrig/ T2

ReadEvent_2

EventComTrig/ T9 [Events complete]/ T6

[Details read]/ T4

[Events left]/ T5 SignalEvent_3

1520 1521 1522 1523 Figure 51 Master state machine of the event handler Table 51 shows the state transition tables of the Master event handler. Table 51 State transition tables of the Master event handler
STATE NAME Inactive_0 Idle_1 ReadEvent_2 SignalEvent_3 Waiting on activation Waiting on next event indication or event confirmation Read event data set from Device Decompose event data and cast DL_Event to application layer (7.2.1.15) STATE DESCRIPTION

61131-9/WD V0.5 IEC

STATE NAME

91
STATE DESCRIPTION

Working Draft

1524

EventConfirmation_4 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 SOURCE STATE 0 1 2 2 3 3 2 1 4 4

Waiting on event confirmation transmission TARGET STATE 1 2 2 3 2 1 0 4 1 0 TYPE Read event status octet Read octets from event buffer Cast CMD.req with event buffer confirmation by writing to "StatusCode" (Table 50) DEFINITION ACTION

1525

INTERNAL ITEMS None

1526 1527 1528 7.3.8.4 Device state machine of the event handler

Figure 52 shows the Device state machine of the event handler.

ModifyEventPage/ T2 EH_Config_ACTIVE/ T1 Idle_1 DL_EventTrigger/ T3 [EventRead]/ T4

/Initialization Inactive_0

FreezeEventTable_2

EH_Config_INACTIVE/ T7 [EventRead]/ T6

EventConf/ T5

1529 1530 1531 1532

Figure 52 Device state machine of the event handler Table 52 shows the state transition tables of the Device event handler. Table 52 State transition tables of the Device event handler
STATE NAME Inactive_0 Idle_1 Waiting on activation Waiting on firing event flag Reading event buffer and waiting on event buffer confirmation TARGET STATE 1 1 2 2 Change event table entries Indicate activated event flag state to frame handler Send event data by casting CMD.rsp with event data ACTION STATE DESCRIPTION

1533

FreezeEventTable_2 TRANSITION T1 T2 T3 T4 SOURCE STATE 0 1 1 2

Working Draft
TRANSITION T5 T6 SOURCE STATE 2 1 1 TARGET STATE 1 1 0 TYPE Service Service Service

92
ACTION

61131-9/WD V0.5 IEC

Indicate cleared event flag state to frame handler. Mark all events as changeable Send event data by casting CMD.rsp with event data DEFINITION Any changes within the event buffer by DL_Event CMD.ind(R, EVENT, Address, ...) CMD.ind(W, EVENT, 0, DontCare)

1534

T7

INTERNAL ITEMS ModifyEventPage EventRead EventConf

1535 1536 1537 1538 1539

8
8.1

Application layer
General

Figure 53 provides an overview of the structure and services of the Master application layer (AL).
Master applications Gateway application (configuration, parameterization, diagnosis, on-request, and process data) Configuration Manager Data Storage On-request Data Exchange Diagnosis Unit Process Data Exchange
AL_NewInput AL_SetOutput DL_PDCycle AL_PDCycle

AL_Control

SM_GetPortConfig

SM_SetPortConfig

SM_PortMode

SM_Operate

AL_Write

On-request data AL objects Application Layer

DL_Control

AL_Abort

AL_GetInput DL_PDOutputUpdate

AL_Read

AL_Event

Process data objects

DL_PDInputTransport

Port x Handler Coordination

AL_Read DL_Read DL_Write DL_SetMode

DL_EventConf

DL_ReadParam

DL_WriteParam

DL_ISDUTransport

DL_ISDUAbort

DL_Event

On-request data handler

Process data handler

SIO DI / DO

1540 1541 1542 1543

System Management

Data Link Layer

Figure 53 Structure and services of the application layer (Master) Figure 54 provides an overview of the structure and services of the Device application layer (AL).

61131-9/WD V0.5 IEC

93
Device applications

Working Draft

Technology specific application (technology parameter, diagnosis, process data) Parameter Manager (PM) Data Storage (DS) Event Dispatcher (ED) Process Data Exchange (PDE)
AL_NewOutput AL_GetOutput

SM_GetDeviceComm

SM_SetDeviceComm

SM_SetDeviceMode

SM_GetDeviceIdent

SM_SetDeviceIdent

SM_DeviceMode

On-request data AL objects Application Layer

DL_Control

AL_Abort

AL_Write

Process data objects

DL_PDOutputTransport DL_PDInputUpdate DL_PDCycle

DL_Event

DL_EventTrigger

DL_ISDUTransport

DL_ReadParam

DL_ISDUAbort

DL_WriteParam

AL_PDCycle

AL_Control

AL_SetInput

AL_Read

AL_Event

1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 8.2

System management

Line handler

On-request data handler

Process data handler

SIO DI / DO

Data Link Layer

Figure 54 Structure and services of the application layer (Device)

Application layer services AL services within Master and Device

8.2.1

This clause defines the services of the application layer (AL) to be provided to the Master and Device applications and system management via its external interfaces. Table 53 lists the assignments of Master and Device to their roles as initiator or receiver for the individual AL services. Empty fields indicate no availability of this service on Master or Device. Table 53 AL services within Master and Device
Service name AL_Read AL_Write AL_Abort AL_GetInput AL_NewInput AL_SetInput AL_PDCycle AL_GetOutput AL_NewOutput AL_SetOutput AL_Event AL_Control Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service R I/R R R I Master R R R R I R I R I Device I I I

1554

Working Draft 1555 1556 1557 1558 1559 8.2.2 8.2.2.1 AL Services AL_Read

94

61131-9/WD V0.5 IEC

The AL_Read service is used to read on-request data from a Device connected to a specific port. The parameters of the service primitives are listed in Table 54. Table 54 AL_Read
Parameter name Argument Port Index Subindex M M M M M M .req M .ind .rsp .cnf

Result (+) Port Data

S(=) M

M(=)

Result (-) Port ErrorInfo

S(=) M

M(=)

1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586

Argument The service-specific parameters of the service request are transmitted in the argument. Port This parameter specifies the port number for the on-request data to be read. Parameter type: Unsigned8 Index This parameter specifies the address of on-request data objects to be read from the Device. Index 0 in conjunction with Subindex 0 addresses the entire set of direct parameters from 0 to 15 (see direct parameter page 1 in Table B.1) or in conjunction with Subindices 1 to 16 the individual parameters from 0 to 15. Index 1 in conjunction with Subindex 0 addresses the entire set of direct parameters from addresses 16 to 31 (see direct parameter page 2 in Table B.1) or in conjunction with Subindices 1 to 16 the individual parameters from 16 to 31. It uses the page communication channel (Figure 5) for both and always returns a positive result. For all the other indices (B.2) the ISDU communication channel is used. Permitted values: 0 to 65 535 (See B.2.1 for constraints) Subindex This parameter specifies the element number within a structured on-request data object. A value of 0 indicates the entire set of elements. Permitted values: 0 to 255 Result (+): This selection parameter indicates that the service request has been executed successfully. Port This parameter specifies the port number of the on-request data to be read. Data This parameter specifies the read values of the on-request data.

61131-9/WD V0.5 IEC 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 8.2.2.2 AL_Write Parameter type: Octet string

95

Working Draft

Result (-): This selection parameter indicates that the service request failed. Port This parameter specifies the port number for the requested on-request data. ErrorInfo This parameter contains error information to supplement the Result parameter. Parameter type: ErrorType (Annex C) Permitted values: NO_COMM, STATE_CONFLICT, TIMEOUT, or equivalents to Annex C

The AL_Write service is used to write on-request data to a Device connected to a specific port. The parameters of the service primitives are listed in Table 55. Table 55 AL_Write
Parameter name Argument Port Index Subindex Data M M M M M M M M(=) .req M .ind .rsp .cnf

Result (+) Port

S(=) M

Result (-) Port ErrorInfo

S(=) M

M(=)

1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616

Argument The service-specific parameters of the service request are transmitted in the argument. Port This parameter specifies the port number for the on-request data to be written. Parameter type: Unsigned8 Index This parameter specifies the address of on-request data objects to be written to the Device. Index 0 always returns a negative result. Index 1 in conjunction with Subindex 0 addresses the entire set of direct parameters from addresses 16 to 31 (see Direct Parameter page 2 in Table B.1) or in conjunction with subindices 1 to 16 the individual parameters from 16 to 31. It uses the page communication channel (Figure 5) in case of Index 1 and always returns a positive result. For all the other Indices (B.2) the ISDU communication channel is used. Permitted values: 1 to 65 535 (Table 91) Subindex

Working Draft 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 8.2.2.3 AL_Abort

96

61131-9/WD V0.5 IEC

This parameter specifies the element number within a structured on-request data object. A value of 0 indicates the entire set of elements. Permitted values: 0 to 255 Data This parameter specifies the values of the on-request data to be written. Parameter type: Octet string Result (+): This selection parameter indicates that the service request has been executed successfully. Port This parameter specifies the port number of the on-request data to be written. Result (-): This selection parameter indicates that the service request failed. Port This parameter specifies the port number for the requested on-request data. ErrorInfo This parameter contains error information to supplement the Result parameter. Parameter type: ErrorType (Annex C) Permitted values: NO_COMM, STATE_CONFLICT, TIMEOUT or equivalents to Annex C

The AL_Abort service is used to abort a current AL_Read or AL_Write service on a specific port. Call of this service abandons the response to an AL_Read or AL_Write service in progress on the Master. The parameters of the service primitives are listed in Table 55. Table 56 AL_Abort
Parameter name Argument Port M M .req M .ind

1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651

Argument The service-specific parameters of the service request are transmitted in the argument. Port This parameter specifies the port number of the services to be abandoned.

8.2.2.4

AL_GetInput

The AL_GetInput service reads the input data within the process data provided by the data link layer of a Device connected to a specific port. The parameters of the service primitives are listed in Table 57.

61131-9/WD V0.5 IEC 1652

97 Table 57 AL_GetInput
Parameter name .req M M .cnf

Working Draft

Argument Port

Result (+) Port InputData

S M M

Result (-) Port ErrorInfo

S M M

1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678

Argument The service-specific parameters of the service request are transmitted in the argument. Port This parameter specifies the port number for the process data to be read. Result (+): This selection parameter indicates that the service request has been executed successfully. Port This parameter specifies the port number for the process data to be read. InputData This parameter contains the values of the requested process input data of the specified port. Parameter type: Octet string Result (-): This selection parameter indicates that the service request failed. Port This parameter specifies the port number for the process data to be read. ErrorInfo This parameter contains error information to supplement the Result parameter. Parameter type: ErrorType (Annex C) Permitted values: NO_COMM, NOT_CONNECTED, NO_DATA or equivalent to Annex C

8.2.2.5

AL_NewInput

The AL_NewInput local service indicates the receipt of updated input data within the process data of a Device connected to a specific port. The parameters of the service primitives are listed in Table 58. Table 58 AL_NewInput
Parameter name Argument Port M M .ind

1679 1680

Argument The service-specific parameters of the service request are transmitted in the argument.

Working Draft 1681 1682 1683 1684 1685 1686 1687 8.2.2.6 AL_SetInput

98

61131-9/WD V0.5 IEC

Port This parameter specifies the port number of the received process data.

The AL_SetInput local service updates the input data within the process data of a Device. The parameters of the service primitives are listed in Table 59. Table 59 AL_SetInput
Parameter name Argument InputData M M .req .cnf

Result (+)

Result (-) ErrorInfo

S M

1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708

Argument The service-specific parameters of the service request are transmitted in the argument. InputData This parameter contains the process data values of the input data to be transmitted. Parameter type: Octet string Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request has failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Parameter type: ErrorType (Annex C) Permitted values: STATE_CONFLICT or equivalent to Annex C

8.2.2.7

AL_PDCycle

The AL_PDCycle local service indicates the end of a process data cycle. The Device application can use this service to transmit new input data to the application layer via AL_SetInput. The parameters of the service primitives are listed in Table 60. Table 60 AL_PDCycle
Parameter name Argument Port O .ind

1709 1710 1711

Argument The service-specific parameters of the service request are transmitted in the argument.

61131-9/WD V0.5 IEC 1712 1713 1714 1715 1716 1717 1718 8.2.2.8 AL_GetOutput

99

Working Draft

Port This parameter specifies the port number of the received new process data.

The AL_GetOutput service reads the output data within the process data provided by the data link layer of the Device. The parameters of the service primitives are listed in Table 61. Table 61 AL_GetOutput
Parameter name Argument M .req .cnf

Result (+) OutputData

S M

Result (-) ErrorInfo

S M

1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742

Argument The service-specific parameters of the service request are transmitted in the argument. Result (+): This selection parameter indicates that the service request has been executed successfully. OutputData This parameter contains the process data values of the requested output data for the specified port. Parameter type: Octet string Result (-): This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Parameter type: ErrorType (Annex C) Permitted values: NO_COMM, NOT_CONNECTED, equivalents to Annex C NO_DATA, CONFIG_FAULT or

8.2.2.9

AL_NewOutput

The AL_NewOutput local service indicates the receipt of updated output data within the process data of a Device. This service has no parameters.

8.2.2.10

AL_SetOutput

The AL_SetOutput local service updates the output data within the process data of a Master. The parameters of the service primitives are listed in Table 62.

Working Draft 1743

100 Table 62 AL_SetOutput

Parameter name Argument Port OutputData M M M .req

61131-9/WD V0.5 IEC

.cnf

Result (+) Port

S M

Result (-) Port ErrorInfo

S M M

1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770

Argument The service-specific parameters of the service request are transmitted in the argument. Port This parameter specifies the port number of the process data to be written. OutputData This parameter contains the ProcessDataIn the output data to be written at the specified port. Parameter type: Octet string Result (+): This selection parameter indicates that the service request has been executed successfully. Port This parameter specifies the port number for the process data to be written. Result (-): This selection parameter indicates that the service request failed. Port This parameter specifies the port number for the process data to be written. ErrorInfo This parameter contains error information to supplement the Result parameter. Parameter type: ErrorType (Annex C) Permitted values: STATE_CONFLICT or equivalents to Annex C 8.2.2.11 AL_Event

The AL_Event service indicates up to 6 pending status or error messages. The source of one event can be local (Master) or remote (Device). The event can be triggered by a communication layer or by an application. The parameters of the service primitives are listed in Table 63. Table 63 AL_Event
Parameter name Argument Port EventCount M M .req M M M .ind M M .rsp .cnf

61131-9/WD V0.5 IEC

Parameter name Event(1) Instance Mode Type Local EventCode Event(n) Instance Mode Type Local EventCode

101
.req M M M M M M M M M .ind .rsp .cnf

Working Draft

M M M

M M M M

1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798

Argument The service-specific parameters of the service request are transmitted in the argument. Port This parameter specifies the port number of the event data. EventCount This parameter specifies the number n (16) of Events in the Event buffer. Event(x) Depending on EventCount this parameter exists n times. Each instance contains the following elements. Instance This parameter specifies the event source. Permitted values: unknown, PL, DL, AL, Application Mode This parameter specifies the event mode. Permitted values: SINGLESHOT, APPEARS, DISAPPEARS Type This parameter specifies the event category. Permitted values: ERROR, WARNING, MESSAGE Local This parameter indicates that the event was generated in the local communication section. Permitted values: LOCAL, REMOTE EventCode This parameter contains a code identifying the event. Permitted values: see Annex C 8.2.2.12 AL_Control

The AL_Control service contains the process data state information transmitted to the Device application. The parameters of the service primitives are listed in Table 64.

Working Draft 1799

102 Table 64 AL_Control

Parameter name Argument Port ControlCode M C M .req M C M

61131-9/WD V0.5 IEC

.ind

1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820

Argument The service-specific parameters are transmitted in the argument. Port This parameter specifies the port number of the event data. ControlCode This parameter contains a code identifying the state of the process data. Permitted values: PD_VALID, PD_INVALID

8.3 8.3.1

Application layer protocol Overview

Figure 6 shows that the application layer offers services for data objects which are transformed into the special communication channels of the data link layer. The application layer manages the data transfer with all its assigned ports. That means, AL service calls need to identify the particular port they are related to. 8.3.2 8.3.2.1 On-request Data transfer OD state machine of the Master AL

Figure 55 shows the state machine for the handling of On-request Data (OD) within the application layer. "AL_Service" represents any AL service in Table 53 related to OD. "Portx" indicates a particular port number.

61131-9/WD V0.5 IEC

103

Working Draft

/Initialization AL_Service_Portx/ T16

AL_Abort_Portx/ T17

OnReq_Idle_0

AL_Service_Portx/ T1

[Argument_Error]/ T2

Build_DL_Service_1

AL_Read[ Index <=1]/ T3

AL_Write[ Index =1]/ T4

AL_Write[ Index = 2 & Not_ISDU_flag]/ T5

AL_Read[ Index >=2 & ISDU_flag]/ T6

AL_Write[ Index >=2 & ISDU_flag]/ T7

Await_DL_Param_cnf_2

Await_DL_ISDU_cnf_3

AL_Service/ T8

AL_Abort/ T9

DL_RWParam[ Octets_left]/ T10 DL_WriteParam_cnf[ Completed]/ T14 Build_AL_cnf_4

AL_Abort/ T11

AL_Service/ T12

DL_ReadParam_cnf[ Completed]/ T13

DL_ISDUTransport_cnf/ T15

1821 1822 1823 1824 Figure 55 OD state machine of the Master AL Table 65 shows the states and transitions for the OD state machine of the Master AL. Table 65 States and transitions for the OD state machine of the Master AL
STATE NAME OnReq_Idle_0 Build_DL_Service_1 STATE DESCRIPTION AL service calls from the Master applications can be accepted within this state. Within this state AL service calls are checked and corresponding DL services are created within the subsequent states. In case of an error in the arguments of the AL service a negative AL confirmation is created and returned. Within this state the AL service call is transformed in a sequence of as many DL_ReadParam or DL_WriteParam calls as needed (Direct Parameter page access; see page communication channel in Figure 5). All asynchronously occurred AL service calls but an AL_Abort are rejected (see 3.3.6). Within this state the AL service call is transformed in a DL_ISDUTransport service call (see ISDU communication channel in Figure 5). All asynchronously occurred AL service calls but an AL_Abort are rejected (see 3.3.6). Within this state an AL service confirmation is created depending on an argument error, the DL service confirmation, or an AL_Abort. SOURCE STATE 0 1 1 1 TARGET STATE 1 4 2 2 ACTION Memorize the port number "Portx". Prepare negative AL service confirmation. Prepare DL_ReadParam for Index 0 or 1. Prepare DL_WriteParam for Index 1.

Await_DL_Param_cnf_2

Await_DL_ISDU_cnf_3

Build_AL_cnf_4

1825
TRANSITION T1 T2 T3 T4

Working Draft
TRANSITION T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 SOURCE STATE 1 1 1 2 2 2 3 3 2 2 3 4 0 TARGET STATE 2 3 3 2 4 2 4 3 4 4 4 0 0 TYPE Bool Bool Bool Variable Bool

104
ACTION

61131-9/WD V0.5 IEC

Prepare DL_WriteParam for Index 2 if the Device does not support ISDU. Prepare DL_ ISDUTransport(read) Prepare DL_ ISDUTransport(write) Return negative AL service confirmation on this asynchronous service call. All current DL service actions are abandoned and a negative AL service confirmation is prepared. Call next DL_ReadParam or DL_WriteParam service if not all OD are transferred. All current DL service actions are abandoned and a negative AL service confirmation is prepared. Return negative AL service confirmation on this asynchronous service call. Prepare positive AL service confirmation. Prepare positive AL service confirmation. Prepare positive AL service confirmation. Return AL service confirmation with port number "Portx". Return negative AL service confirmation. DEFINITION Illegal values within the service body, for example "Port number or Index out of range" No more OD left for transfer More OD for transfer Service body variable indicating the port number Device supports ISDU

1826

T17

INTERNAL ITEMS Argument_Error Completed Octets_left Portx ISDU_Flag

1827 1828 1829 1830 8.3.2.2 OD state machine of the Device AL

Figure 56 shows the state machine for the handling of On-request Data (OD) within the application layer of a Device.

AL_Abort/T11

/Initialization DL_ISDUAbort/ T10

Await_AL_Write_rsp_1

DL_WriteParam_ind/T1

Idle_0

AL_Write_rsp/T2 AL_Read_rsp/ T7 DL_ISDUTransport _ind[DirRead]/ T5 AL_Write_rsp/ T8

DL_ReadParam_ind/ T3 AL_Read_rsp/ T4 Await_AL_Read_rsp_2

AL_Abort/ T9 Await_AL_RW_rsp_3

DL_ISDUTransport_ind[DirWrite]/ T6

1831 1832 1833 Figure 56 OD state machine of the Device AL Table 66 shows the states and transitions for the OD state machine of the Device AL.

61131-9/WD V0.5 IEC 1834

105

Working Draft

Table 66 States and transitions for the OD state machine of the Device AL
STATE NAME Idle_0 Await_AL_Write_rsp_1 Await_AL_Read_rsp_2 Await_AL_RW_rsp_3 STATE DESCRIPTION The Device AL is waiting on subordinated DL service calls triggered by Master messages. The Device AL is waiting on a response from the technology specific application (write access to Direct Parameter page). The Device AL is waiting on a response from the technology specific application (read access to Direct Parameter page). The Device AL is waiting on a response from the technology specific application (read or write access via ISDU). TARGET STATE 1 0 2 0 3 3 0 0 0 0 0 TYPE Bool Bool Create AL_Write. Create DL_WriteParam (1631). Create AL_Read. Create DL_ReadParam (031). Create AL_Read. Create AL_Write. Create DL_ ISDUTransport(read) Create DL_ ISDUTransport(write) Current AL_Read or AL_Write abandoned upon this asynchronous AL_Abort service call. Return negative DL_ ISDUTransport (see 3.3.6). Current waiting on AL_Read or AL_Write abandoned. Current DL_ ISDUTransport abandoned. All OD are set to "0". DEFINITION Access direction: DL_ ISDUTransport(read) causes an AL_Read Access direction: DL_ ISDUTransport(write) causes an AL_Read ACTION

1835
TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 SOURCE STATE 0 1 0 2 0 0 3 3 3 3 0

1836

T11

INTERNAL ITEMS DirRead DirWrite

1837 1838 1839 1840 1841 1842 1843 1844 8.3.2.3 Sequence diagrams for On-request Data

Figure 57 through Figure 59 demonstrate complete interactions between Master and Device for several On-request Data exchange use cases. Figure 57 demonstrates two examples for the exchange of On-request Data. For Indices > 1 this is performed with the help of ISDUs and corresponding DL services (ISDU communication channel according to Figure 5). Access to Direct Parameter pages 0 and 1 uses different DL services (page communication channel according to Figure 5)

Working Draft
Master App Master AL Master DL Portx

106
Device DL

61131-9/WD V0.5 IEC

Device AL Device App

AL_Read_req(Index > 1) Read Parameter via ISDU DL_ISDUTransport_req() Message() DL_ISDUTransport_ind() AL_Read_ind() AL_Read_rsp() DL_ISDUTranspot_rsp() Message() DL_ISDUTransport_cnf() AL_Read_cnf()

AL_Read_req(Index <= 1) Read Direct Parameter page 0 or 1 DL_ReadParam_ind() Message()

DL_ReadParam_ind() AL_Read_ind(Index <=1)

AL_Read_rsp() DL_ReadParam_rsp() Message() DL_ReadParam_cnf() AL_Read_cnf()

1845 1846 1847 1848 1849 1850 1851 1852 1853 Figure 57 Sequence diagram for the transmission of On-request Data Figure 58 demonstrates the behaviour of On-request Data exchange in case of an error such as requested Index not available (Table C.1). Another possible error occurs when the Master application (gateway) tries to read an Index > 1 from a Device, which does not support ISDU. The Master AL would respond immediately with "NO_ISDU_SUPPORTED" as the features of the Device are acquired during start-up through reading the Direct Parameter page 1 via the parameter "F-sequence Capability" (Table B.1).

61131-9/WD V0.5 IEC

Master App Master AL Master DL Portx

107
Device DL Device AL

Working Draft
Device App

AL_Read_req(Index > 1) DL_ISDUTransport_req() Message() DL_ISDUTransport_ind() Device application responds with error information "Index not available" (0x8011, IDX_NOTAVAIL)

AL_Read_ind()

AL_Read_rsp() DL_ISDUTransport_rsp() Message() AL_Read_cnf() ErrorInfo: IDX_NOTAVAIL DL_ISDUTransport_cnf() ErrorInfo: IDX_NOTAVAIL

1854 1855 1856 1857 1858 Figure 58 Sequence diagram for On-request Data in case of errors Figure 59 demonstrates the behaviour of On-request Data exchange in case of an ISDU timeout (5 500 ms). A Device shall respond within less than 5 000 ms (10.7.4).
NOTE See Table 91 for system constants such as ISDU timeout.
Master AL Master DL Portx Device DL Device AL Device App

Master App

AL_Read_req() DL_ISDUTransport_req() Message()

DL_ISDUTransport_ind() AL_Read_ind() Tm(5500) <5000 ms>

DL_ISDUTransport_cnf() AL_Read_cnf() ErrorInfo = TIMEOUT ErrorInfo = TIMEOUT Reaction of the Device application missing or too late (usually an implementation error) Message() AL_Read_rsp()

FlowCTRL = Abort

DL_Abort_ind() AL_Abort_ind() Abort current ISDU action

1859 1860 Figure 59 Sequence diagram for On-request Data in case of timeout

Working Draft 1861 1862 1863 8.3.3 8.3.3.1 Event processing

108

61131-9/WD V0.5 IEC

Event state machine of the Master AL

Figure 60 shows the Event state machine of the Master application layer.

/Initialization Event_inactive_0

Activate/ T1 Event_idle_1

Deactivate/ T2

DL_Event_ind[Diag_Portx]/ T3

AL_Event_rsp/ T6

Read_Event_Set_2

DL_Event_ind[Events_done]/ T5

DU_Event_handling_3

1864 1865 1866 1867 1868

DL_Event_ind[Events_left]/ T4

Figure 60 Event state machine of the Master AL Table 67 specifies the states and transitions of the Event state machine of the Master application layer. Table 67 State and transitions of the Event state machine of the Master AL
STATE NAME Event_inactive_0 Event_idle_1 Read_Event_Set_2 STATE DESCRIPTION The AL Event handling of the Master is inactive. The Master AL is ready to accept DL_Events (diagnosis information) from the DL. The Master AL received a DL_Event_ind with diagnosis information. After this first DL_Event.ind, the AL collects the complete set (1 to 6) of DL_Events of the current EventTrigger (see 11.5). The Master AL remains in this state as long as the Diagnosis Unit (see 11.5) did not acknowledge the AL_Event.ind. TARGET STATE 1 0 2 2 3 1 TYPE Bool Bool Bool AL_Event.ind DL_EventConf.req DEFINITION Event set contains diagnosis information with details. Event set is processed. Event set not yet completed. ACTION

DU_Event_handling_3

1869
TRANSITION T1 T2 T3 T4 T5 SOURCE STATE 0 1 1 2 2 3

1870

T6

INTERNAL ITEMS Diag_Portx Events_done Events_left

61131-9/WD V0.5 IEC 1871 1872 8.3.3.2

109

Working Draft

Event state machine of the Device AL

Figure 61 shows the Event state machine of the Device application layer

/Initialization

Event_inactive_0

Activate/ T1 Event_idle_1

Deactivate/ T2

AL_Event_req/ T3

DL_EventTrigger_cnf/ T4

Await_Event_response_2

1873 1874 1875 1876 1877 Figure 61 Event state machine of the Device AL Table 68 specifies the states and transitions of the Event state machine of the Device application layer Table 68 State and transitions of the Event state machine of the Device AL
STATE NAME Event_inactive_0 Event_idle_1 STATE DESCRIPTION The AL Event handling of the Device is inactive. The Device AL is ready to accept AL_Events (diagnosis information) from the technology specific Device applications for the transfer to the DL. The Device applications can create new Events during this time. The Device AL propagated an AL_Event with diagnosis information and waits on a DL_EventTrigger confirmation of the DL. The Device applications are not permitted to create new Events during this time. TARGET STATE 1 0 2 An AL_Event request triggers a DL_Event and the corresponding DL_EventTrigger service. The DL_Event carries the diagnosis information from AL to DL. The DL_EventTrigger sets the Event flag within the cyclic data exchange (see A.1.5) A DL_EventTrigger confirmation triggers an AL_Event confirmation. TYPE DEFINITION ACTION

Await_event_response_2

1878
TRANSITION T1 T2 T3 SOURCE STATE 0 1 1

1879
none

T4

INTERNAL ITEMS

1880 1881 1882 1883 1884 8.3.4 Process data cycles

Figure 62 and Figure 63 demonstrate complete interactions between Master and Device for output and input Process Data use cases.

Working Draft 1885 1886 1887

110

61131-9/WD V0.5 IEC

Figure 62 demonstrates how the AL and DL services of Master and Device are involved in the cyclic exchange of output Process Data. The Device application is able to acquire the current values of output PD via the AL_GetOutput service.
Mast er App Mast er AL Mast er DL Portx Dev ice DL Dev ice AL Dev ice App

AL_Set Output_req(Portx ) DL_PDOutputUpdate_req() Message()

DL_PDOutputTransport_ind() AL_Set Output_req(Portx ) <Cy cle time> AL_NewOutput_ind()

...
AL_Set Output_req(Portx )

DL_PDOutputUpdate_req() Message()

...
DL_PDOutputUpdate_req() Message()

...

DL_PDOutputTransport_ind()

...
DL_PDOutputTransport_ind()

AL_NewOutput_ind()

...
AL_NewOutput_ind()

Asynchronous ac cess to output Proc ess Data

AL_Get Output_req()

AL_Get Output_cnf ()

1888 1889 1890 1891 1892 Figure 62 Sequence diagram for output Process Data Figure 63 demonstrates how the AL and DL services of Master and Device are involved in the cyclic exchange of input Process Data. The Master application is able to acquire the current values of input PD via the AL_GetInput service.

61131-9/WD V0.5 IEC

Master App Master AL Master DL Portx

111
Device DL Device AL

Working Draft
Device App

Message() DL_PDCycle_ind() AL_PDCycle_ind() DL_PDInputTransport_req() AL_NewInput_ind() <Cycle time> DL_PDInputUpdate_req() Device application sets input Process Data for cyclic transmission by the frame handler Message() DL_PDCycle_ind() AL_PDCycle_ind() AL_SetInput_req()

DL_PDInputUpdate_cnf() AL_SetInput_cnf()

DL_PDInputTransport_req() AL_NewInput_ind()

...
Message()

...
DL_PDCycle_ind()

...
AL_PDCycle_ind()

...
AL_NewInput_ind()

...
DL_PDInputTransport_req()

AL_GetInput_req()

AL_GetInput_cnf()

Asynchronous access to input Process Data

1893 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 Figure 63 Sequence diagram for input Process Data

9
9.1

System management (SM)

General

The SDCI system management is responsible for the coordinated startup of the ports within the Master and the corresponding operations within the connected Devices. The difference between the SM of the Master and the Device is more significant than with the other layers. Consequently, the structure of this clause separates the services and protocols of Master and Device. 9.2 9.2.1 System management of the Master Overview

The Master system management services are used to set up the Master system for all possible operational modes such as "wake-up", "startup", "preoperate", and "operate". The Master SM adjusts ports through establishing the required communication protocol revision checking the Device compatibility (actual Device identifications match expected values) adjusting adequate Master F-sequence types and MasterCycleTimes

Working Draft 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922

112

61131-9/WD V0.5 IEC

For this it uses the following services shown in Figure 64: SM-SetPortConfig transfers the necessary Device parameters (configuration data) from Configuration Management (CM) to System Mangement (SM). The port is then started implicitely. SM-PortMode reports the positive result of the port setup back to CM in case of correct port setup and validation. It reports the negative result back to CM via corresponding "errors" in case of mismatching revisions and incompatible Devices. SM-GetPortConfig provides the actual and effective parameters. SM-Operate switches the ports into the "Operate" mode.

Figure 64 provides an overview of the structure and services of the Master system management. The Master system management needs one application layer service (AL_Read) to acquire data (identification parameter) from special Indices for validation.
Master applications Gateway application (configuration, parameterization, diagnosis, on-request, and process data) Configuration Manager
SM_Operate SM_GetPortConfig SM_SetPortConfig

Data Storage

On-request Data Exchange

Diagnosis Unit

Process Data Exchange

SM_PortMode

Application Layer
DL_PDInputTransport PDTrig PD.cnf DL_Write Param DL_PDCycle DL_Event DL_EventConf DL_ReadParam DL_PDOutputUpdate DL_Control DL_ISDUTransport DL_ISDUAbort

Port x Handler

AL_Read

DL_Read Coordination DL_Write DL_SetMode

On-request data handler

EventFlag.ind

Process data handler DL-B

PD.req

CMD.cnf

PDInvalid

CMD.req

ComTrig

DL-A

System Management

DL_Mode

Master DL-mode handler

FHInfo CMD.req CMD.cnf

Frame handler
PL_Transfer.req PL_Transfer.ind

SIO DI / DO

PL_Mode.req Mode switch Inactive

PL_WakeUp.req

(Wake-up)

(Coded switching)

(Switching signal)

1923 1924 1925 1926 1927 1928 1929 1930 1931 1932

Physical Layer (port)

Figure 64 Structure and services of the Master system management Figure 65 demonstrates the actions between the layers Master application (Master App), Configuration Management (CM), System Management (SM), Data Link (DL) and Application Layer (AL) for the startup use case of a particular port. This particular use case is characterized by the following statements: The Device for the available configuration is connected and validation is OK The Device uses the correct protocol version according to this specification The configured InspectionLevel is "type compatible" (SerialNumber is read out of the Device and not checked).

61131-9/WD V0.5 IEC 1933 1934

Master App CM

113

Working Draft

Dotted arrows in Figure 65 represent response services to an initial service.

SM

AL_Port_x

DL_Port_x

OperatingMode(SDCI) (Port x)

SM_SetPortConfig_req() (Parameter list) DL_SetMode_req() (Startup) DL_Mode_ind(STARTUP) DL_Read() Reply() (Direct Parameter 1)

Actions: - Wake up - Transmission rate detected - --> State STARTUP Actions: - Read Direct Parameter 1

Actions: - Check protocol revision - Check device compatibility - Frametype (PREOPERATE) - Cycle time (PREOPERATE)

...

DL_SetMode_req(PREOPERATE) (Value list) DL_Mode_ind(PREOPERATE)

Actions: --> State PREOPERATE

AL_Read() Actions: - Check "Serial Number" Reply() (Index: Serial number)

SM_PortMode_ind(CFGCOM) OperatingMode(SDCI) SM_GetPortConfig_req() Reply() (Parameter list) Operate() (Port x) SM_Operate() Actions: - Frametype (OPERATE) - Master Cycle Time (OPERATE) Actions: --> State OPERATE

DL_SetMode_req() (OPERATE, Parameter list) DL_Mode_ind(OPERATE) SM_PortMode_ind(OPERATE)

1935 1936 1937 1938 1939 1940 1941 1942 9.2.2 9.2.2.1 SM Master services Overview Figure 65 Sequence chart of the use case "port x setup"

System management provides the SM Master services to the user via its upper interface. Table 69 lists the assignment of the Master to its role as initiator or receiver for the individual SM services.

Working Draft 1943

114 Table 69 SM services within the Master

Service name SM_SetPortConfig SM_GetPortConfig SM_PortMode SM_Operate Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service Master R R I R

61131-9/WD V0.5 IEC

1944 1945 1946 1947 1948 9.2.2.2 SM_SetPortConfig

The SM_SetPortConfig service is used to set up the requested Device configuration. The parameters of the service primitives are listed in Table 70. Table 70 SM_SetPortConfig
Parameter name Argument ParameterList M M .req .cnf

Result (+) Port Number

S M

Result (-) Port Number ErrorInfo

S M M

1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968

Argument The service-specific parameters of the service request are transmitted in the argument. ParameterList This parameter specifies the configured Device parameter on a Master port. Parameter type: Record Record Elements: Port Number This parameter specifies the port number ConfiguredCycleTime This parameter specifies the requested cycle time for OPERATE mode Permitted values: 0 = FreeRunning, time in s TargetMode This parameter specifies the requested operational mode Permitted values: INACTIVE, DI, DO, CFGCOM, AUTOCOM (see Table 72) ConfiguredBaudrate: This parameter specifies the requested transmission rate Permitted values : AUTO, COM1, COM2, COM3 ConfiguredRevisionID (CRID): Data length: 1 octet for the protocol version (see B.1.6)

61131-9/WD V0.5 IEC 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993

115

Working Draft

InspectionLevel: Permitted values: NO_CHECK, TYPE_COMP, IDENTICAL (see Table 71) ConfiguredVendorID (CVID) Data length: 2 octets from the official vendor list (see Annex K) ConfiguredDeviceID (CDID) Data length: 3 octets ConfiguredFunctionID (CFID) Data length: 2 octets ConfiguredSerialNumber (CSN) Data length: up to 16 octets Result (+): This selection parameter indicates that the service request has been executed successfully Port Number This parameter specifies the port number Result (-): This selection parameter indicates that the service request failed Port Number This parameter specifies the port number ErrorInfo This parameter contains error information to supplement the Result parameter Permitted values: OUT_OF_RANGE, STATE_CONFLICT Table 71 specifies the coding of the different InspectionLevels (IL). Table 71 Definition of the InspectionLevel (IL)
Parameter NO_CHECK DeviceID (compatible) VendorID SerialNumber InspectionLevel (IL) TYPE_COMP yes yes IDENTICAL yes yes yes

1994 1995 1996 Table 72 specifies the coding of the different Target Modes. Table 72 Definitions of the Target Modes
Target Mode CFGCOM AUTOCOM INACTIVE DI DO Definition Device communicating in mode CFGCOM after successful validation Device communicating in mode AUTOCOM without validation Communication disabled, no DI, no DO Port in digital input mode (SIO) Port in digital output mode (SIO)

1997

Working Draft 1998 1999 2000 2001 2002 2003 2004 2005

116

61131-9/WD V0.5 IEC

CFGCOM is a Target Mode based on a configuration with the help of an IODD and consistency checking of RID, VID, DID. AUTOCOM is a Target Mode without configuration. That means no checking of CVID and CDID. The CRID is set to the highest revision the Master is supporting. 9.2.2.3 SM_GetPortConfig

The SM_GetPortConfig service is used to acquire the real (actual) Device configuration. The parameters of the service primitives are listed in Table 73. Table 73 SM_GetPortConfig
Parameter name Argument Port Number M M .req .cnf

Result (+) Parameterlist

S(=) M

Result (-) Port Number ErrorInfo

S(=) M M

2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031

Argument The service-specific parameters of the service request are transmitted in the argument. Port Number This parameter specifies the port number Result (+): This selection parameter indicates that the service request has been executed successfully. ParameterList This parameter specifies the configured Device parameter on a Master port. Parameter type: Record Record Elements: PortNumber This parameter specifies the port number. TargetMode This parameter indicates the operational mode Permitted values: INACTIVE, DI, DO, CFGCOM, AUTOCOM RealBaudrate This parameter indicates the actual transmission rate Permitted values: COM1, COM2, COM3 RealCycleTime This parameter indicates the real (actual) cycle time RealRevision (RRID) Data length: 1 octet for the protocol version (see B.1.6) RealVendorID (RVID) Data length: 2 octets from the official vendor list (Annex K) RealDeviceID (RDID)

61131-9/WD V0.5 IEC 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 Data length: 3 octets RealFunctionID (RFID) Data length: 2 octets RealSerialNumber (RSN) Data length: up to 16 octets

117

Working Draft

Result (-): This selection parameter indicates that the service request failed Port Number This parameter specifies the port number ErrorInfo This parameter contains error information to supplement the Result parameter Permitted values: OUT_OF_RANGE All parameters shall be set to "0" if there is no information available. 9.2.2.4 SM_PortMode

The SM_PortMode service is used to indicate changes or faults of the local communication mode. The parameters of the service primitives are listed in Table 74. Table 74 SM_PortMode
Parameter name Argument Port Number Mode M M M .ind

2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059

Argument The service-specific parameters of the service request are transmitted in the argument. Port Number This parameter specifies the port number Mode Permitted values: INACTIVE, DI, DO, CFGCOM, SM_OPERATE; see Table 75 for the port error modes: COMLOSS, REV_FAULT, COMP_FAULT, and SERNUM_FAULT Table 75 defines the port error modes. These shall be reported to the Master application. Table 75 Definition of the port error modes
Mode COMLOSS REV_FAULT COMP_FAULT SERNUM_FAULT Definition Communication failed, new wake-up procedure required Incompatible protocol revision Incompatible Device according to the InspectionLevel Mismatching SerialNumber according to the InspectionLevel

2060

Working Draft 2061 2062 2063 2064 2065 9.2.2.5 SM_Operate

118

61131-9/WD V0.5 IEC

The SM_Operate service prompts system management to calculate the MasterCycleTimes of the ports when they are acknowledged positively with Result (+). This service is effective on all the ports. The parameters of the service primitives are listed in Table 76. Table 76 SM_Operate
Parameter name Result (+) .req S .cnf

Result (-) ErrorInfo

S M

2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091

Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: TIMING_CONFLICT

9.2.3 9.2.3.1

SM Master protocol Overview

Due to the comprehensive configuration, parameterization, and operational features of SDCI the description of the behavior with the help of state diagrams becomes rather complex. Similar to the DL state machines this section uses the possibility of submachines within the main state machines. Comprehensive compatibility check methods are performed within the submachine states. These methods are indicated by "do method" fields within the state graphs, for example in Figure 67. The corresponding decision logic is demonstrated via activity diagrams (Figure 68, Figure 69, Figure 70, and Figure 73). 9.2.3.2 SM Master state machine

Figure 66 shows the main state machine of the System Mangement Master. Two submachines for the compatibility and serial number check are described in subsequent sections. In case of communication disruption the system management is informed via the DL_Mode service (COMLOSS). Only the SM_SetPortConfig service allows reconfiguration of a port. The service SM_Operate (effective on all ports) causes no effect in any state except in state "wait_4".

61131-9/WD V0.5 IEC

119

Working Draft

/Inialization

PortInactive_0 DL_Mode_COMLOSS/ T3 DL_Mode_STARTUP/ T1 SM_SetPortConfig[INACTIVE]/ T14 SM_SetPortConfig[CFGCOM or AUTOCOM]/ T15

JoinPseudoState_9 enex_6

checkCompatibility_1 enex_1 enex_5 enex_2 [CompOK]/ T2 waitonDLPreoperate_2 enex_3 [CompFault]/ T7 enex_4

[RevisionFault]/ T6

[V10CompOK]/ T4

waitonDLOperate_7

DL_Mode_PREOPERATE/ T8

[V10CompFault]/ T5 ValidationFault_6

DL_Mode_OPERATE/ T9

checkSerNum_3

enex_10 [SerNumFault]/ T11

enex_12

enex_11

[SerNumOK]/ T10

SM_SetPortConfig[DI or DO]/ T16 DIDO_8

wait_4

SM_Operate/ T12 SMOperate_5

2092 2093 2094 2095

DL_Mode_OPERATE/ T13

Figure 66 Main Master state machine of the System Management Table 77 shows the state transition tables of the Master system management. Table 77 State transition tables of the Master system management
STATE NAME PortInactive_0 CheckCompatibility_1 waitonDLPreoperate_2 CheckSerNum_3 wait_4 SM Operate_5 ValidationFault_6 waitonDLOperate_7 No communication Port is started and revision and Device compatibility is checked. See Figure 67. Wait until the state PREOPERATE is established and all the On-Request handlers are started. Port is ready to communicate. SerialNumber is checked depending on the InspectionLevel (IL). See Figure 72. Port is ready to communicate and waits on service SM_Operate from CM. Port is in state OPERATE and performs cyclic process data exchange. Port is ready to communicate. However, cyclic process data exchange cannot be performed due to incompatibilities. Wait on the requested state OPERATE in case of protocol version V1.0. The STATE DESCRIPTION

Working Draft
STATE NAME

120
STATE DESCRIPTION SerialNumber can be read thereafter.

61131-9/WD V0.5 IEC

DIDO_8 JoinPseudoState_9

Port will be switched into the DI or DO mode (SIO, no communication) This pseudo state is used instead of a UML join bar. It allows execution of individual SM_SetPortConfig services depending on the system status (INACTIVE, CFGCOM, AUTOCOM, DI, or DO) TARGET STATE 1 2 0 7 6 6 6 3 3 4 6 5 5 0 0 8 TYPE Bool Bool Bool Bool Bool Bool Bool Variable Variables See Figure 70 See Figure 70; error variable COMP_FAULT See Figure 68; error variable REV_FAULT See Figure 73; error variable SERNUM_FAULT See Figure 73 See Figure 69; error variable COMP_FAULT See Figure 69 A target mode in service SM_SetPortConfig Target Modes in service SM_SetPortConfig CompRetry = 0 DL_SetMode.req (PREOPERATE, ValueList) DL_SetMode.req (INACTIVE ) and SM_Mode.ind (COMLOSS) due to communiacation fault DL_SetMode.req (OPERATE, ValueList) SM_Mode.ind (COMP_FAULT), DL_SetMode.req (OPERATE, ValueList) SM_Mode.ind (REV_FAULT), DL_SetMode.req (PREOPERATE, ValueList) SM_Mode.ind (COMP_FAULT), DL_SetMode.req (PREOPERATE, ValueList) SM_Mode.ind (CFGCOM or AUTOCOM) SM_Mode.ind (SERNUM_FAULT) DL_SetMode.req (OPERATE, ValueList) SM_Mode.ind (INACTIVE), DL_SetMode.req (INACTIVE) DL_SetMode.req (STARTUP, ValueList), PL_Mode.req (SDCI) PL_Mode.req (SIO), SM_Mode.ind (DI or DO), DL_SetMode.req (INACTIVE) DEFINITION ACTION

2096
TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 SOURCE STATE 0 1 1,2,3,4,5, 6,7 1 1 1 1 2 7 3 3 4 5 0,4,5,6,8 0,4,5,6,8 0,4,5,6,8

2097
INTERNAL ITEMS CompOK CompFault RevisionFault SerNumFault SerNumOK V10CompFault V10CompOK INACTIVE CFGCOM, AUTOCOM

2098 2099 2100 9.2.3.3 SM Master submachine "Check Compatibility"

Figure 67 shows the SM Master submachine checkCompatibility_1.

61131-9/WD V0.5 IEC

121
checkCompatibility_1

Working Draft

[WriteDone]/ T24

ReadComParameter_20

[<>V10]/ T21 enex_1 DL_Mode_COMLOSS/ T3 JoinPseudoState_25 CheckVxy_22 do check revision

[V10]/ T20

RestartDevice_24 do write parameter

[RetryStartup]/ T25

[RevisionFault]/ T6

[RetryStartup]/ T23

CheckComp_23 do check comp

[RevisionOK]/ T22

CheckCompV10_21 do check comp V10

[CompOK]/ T2

[CompFault]/ T7

[V10CompOK]/ T4

[V10CompFault]/ T5

2101 2102 2103 2104

enex_2

enex_3

enex_4

enex_5

enex_6

Figure 67 SM Master submachine CheckCompatibility_1 Table 78 shows the state transition tables of the Master submachine checkCompatibility_1. Table 78 State transition tables of the Master submachine CheckCompatibility_1
STATE NAME ReadComParameter_20 CheckCompV10_21 STATE DESCRIPTION Acquires communication parameters from Direct Parameter Page 1 (0x02 to 0x06) via service DL_Read (Table B.1). Acquires identification parameters from Direct Parameter Page 1 (0x07 to 0x0D) via service DL_Read (Table B.1). The configured InspectionLevel (IL) defines the decision logic of the subsequent compatibility check "CheckCompV10" with parameters RVID, RDID, and RFID according to Figure 69. A check is performed whether the configured revision (CRID) matches the real (actual) revision (RRID) according to Figure 68. Acquires identification parameters from Direct Parameter Page 1 (0x07 to 0x0D) via service DL_Read (Table B.1). The configured InspectionLevel (IL) defines the decision logic of the subsequent compatibility check "CheckComp" according to Figure 70. Writes the compatibility parameters configured protocol revision (CRID) and configured DeviceID (CDID) into the Device depending on the Target Mode of communication CFGCOM or AUTOCOM (Table 72) according to Figure 71. This pseudo state is used instead of a UML join bar. No guards involved. TARGET STATE 21 22 23 24 20 24 DL_Write (0x00,0x95 MasterCommand MasterIdent), see Table B.2 CompRetry = CompRetry +1 ACTION

CheckVxy_22 CheckComp_23

RestartDevice_24

2105

JoinPseudoState_25 TRANSITION T20 T21 T22 T23 T24 SOURCE STATE 20 20 22 23 24 22

2106

T25

Working Draft
INTERNAL ITEMS CompOK CompFault RevisionFault RevisionOK SerNumFault SerNumOK V10 <>V10 V10CompFault V10CompOK RetryStartup CompRetry WriteDone TYPE Bool Bool Bool Bool Bool Bool Bool Bool Bool Bool Bool Variable Bool

122
DEFINITION See Figure 70 See Figure 70; error variable COMP_FAULT See Figure 68; error variable REV_FAULT See Figure 68

61131-9/WD V0.5 IEC

See Figure 73; error variable SERNUM_FAULT See Figure 73 Real revision = V1.0 (B.1.6) Real revision <> V1.0 (B.1.6) See Figure 69; error variable COMP_FAULT See Figure 69 See Figure 68 and Figure 70 Internal counter Finalization of the restart service sequence

2107 2108 2109 2110 2111 2112 2113 2114 2115

Some states contain complex logic to deal with the compatibility and validity checks. The following figures are demonstrating the context. Figure 68 shows the decision logic for the protocol revision check in state "CheckVxy". In case of configured Devices the following rule applies: if the configured revision (CRID) and the real revision (RRID) do not match, the CRID will be transmitted to the Device. If the Device does not accept, the Master returns an indication via the SM_Mode service with REV_FAULT. In case of not configured Devices the operational mode AUTOCOM shall be used. See 9.2.2.2 and 9.2.2.3 for the parameter name abbreviations.

D1

[RRID = CRID]

RevisionOK (T22)

[RRID <> CRID]

D2

[CompRetry = 0]

RetryStartup (T23)

[CompRetry = 1]

2116 2117 2118 2119

RevisionFault (T6)

Figure 68 Activity (check revision) for state "CheckVxy"

Figure 69 shows the decision logic for the V10 compatibility check in state "CheckCompV10".

61131-9/WD V0.5 IEC

123

Working Draft

D3

[IL: NO_CHECK]

V10CompOK (T4)

[IL: TYPE_COMP or IDENTICAL]

D4

[CVID = RVID and CDID = RDID]

V10CompOK (T4)

[CVID <> RVID or CDID <> RDID] Key IL = Inspection level

V10CompFault (T5)

2120 2121 2122 2123

Figure 69 Activity (check comp V10) for state "CheckCompV10"

Figure 70 shows the decision logic for the compatibility check in state "CompCheck".

D5

[IL: NO_CHECK]

CompOK (T2)

Device starts

[IL: TYPE_COMP or IDENTICAL]

D6

[CVID <> RVID]

CompFault (T7)

Incompatible --> Error

[CVID = RVID]

[CompRetry = 0 and CDID <> RDID] D7

RetryStartup (T23)

Device restart with RVID, RDID

[CompRetry = 1 and CDID <> RDID] Key IL = Inspection level

CompFault (T7)

Incompatible --> Error

2124 2125 2126 2127 Figure 71 shows the activity (write parameter) in state "RestartDevice". Figure 70 Activity (check comp) for state "CheckComp"

Working Draft

124

61131-9/WD V0.5 IEC

WriteDone =FALSE

DL_Write (0x04, CRID) DL_Write (0x00,0x96, "DeviceIdent") DL_Read (0x02) (dummy cycle)

[AUTOCOM]

D8

[CFGCOM]

DL_Write (0x04, CRID) DL_Write (0x090x0B, CDID) DL_Write (0x00,0x96, "DeviceIdent") DL_Read (0x02) (dummy cycle)

[CommError]

[CommError] [OK] WriteDone = TRUE DL_Mode_COMLOSS (T3)

DL_Mode_COMLOSS (T3)

[OK]

2128 2129 2130 2131 2132 9.2.3.4

(T24)

Figure 71 Activity (write parameter) in state "RestartDevice"

SM Master submachine "Check serial number"

Figure 72 shows the SM Master submachine "checkSerNum_3". This check is mandatory.

checkSerNum_3

ReadSerNum_30 enex_12 DL_Mode_COMLOSS/ T3

[SRead-]/ T30

[SReadOK]/ T31

CheckSerNum_31 do check serial number

[SerNumOK]/ T10

[SerNumFault]/ T11

2133 2134 2135 2136

enex_11

enex_10

Figure 72 SM Master submachine CheckSerNum_3 Table 79 shows the state transition tables of the Master submachine CheckSerNum_3 Table 79 State transition tables of the Master submachine CheckSerNum_3
STATE NAME ReadSerNum_30 STATE DESCRIPTION Acquires the SerialNumber from the Device via AL_Read.req (Index: 0x0015). A positive response (AL_Read(+)) leads to SReadOK = true. A negative response (AL_Read(-)) leads to SRead- = true. The configured (CSN) and the real (RSN) SerialNumber are checked depending on the InspectionLevel (IL) according to Figure 73.

CheckSerNum_31

2137

61131-9/WD V0.5 IEC

TRANSITION T30 SOURCE STATE 40 40 TARGET STATE 41 41 TYPE Bool Bool Bool Bool

125
ACTION

Working Draft

2138

T31

INTERNAL ITEMS SReadSReadOK SERNumOK SERNumFault

DEFINITION Negative response of service AL_Read (Index 0x0015) SerialNumber read correctly See Figure 73 See Figure 73

2139 2140 Figure 73 shows the decision logic (activity) for the state CheckSerNum_3.

D9

[IL: not IDENTICAL] [IL: IDENTICAL]

SerNumOK (T10)

D10

[SRead-]

SerNumFault (T11)

[SReadOK]

[CSN <> RSN] D11

SerNumFault (T11)

[CSN = RSN]

2141 2142 2143 2144 2145 2146 2147 2148 2149 2150 2151 2152 2153 2154 2155 2156 9.2.3.5

SerNumOK (T10)

Figure 73 Activity (check SerialNumber) for state CheckSerNum_3

Rules for the usage of F-sequence types

The System Management is responsible for setting up the correct F-sequence types. This occurs after the check compatibility actions (transition to PREOPERATE) and before the transition to OPERATE. Different F-sequence types shall be used within the different operational states (A.2.6). For example, when switching to the OPERATE state the F-sequence type relevant for cyclic operation shall be used. The F-sequence type to be used in operational state OPERATE is determined by the width of the input and output process data. The available F-sequence types in the three modes STARTUP, PREOPERATE, and OPERATE and the corresponding coding of the parameter F-sequence Capability are defined in A.2.6. The input and output data formats shall be acquired from the connected Device in order to adjust the F-sequence type. It is mandatory for a Master to implement all the specified F-sequence types in A.2.6.

Working Draft 2157 2158 2159 2160 9.3 9.3.1 System management of the Device Overview

126

61131-9/WD V0.5 IEC

Figure 74 provides an overview of the structure and services of the Device system management.
Device applications Technology specific application (technology parameter, diagnosis, process data) Parameter Manager (PM)
SM_GetDeviceComm SM_SetDeviceComm SM_SetDevciceIdent

Data Storage (DS)

Event Dispatcher (ED) Application Layer

Process Data Exchange (PDE)

SM_SetDeviceMode

SM_GetDeviceIdent

SM_DeviceMode

DL_PDOutputTransport

DL_PDInputUpdate

Line Handler
DL_Read DL_Write

On-request data handler

EventFlag

Process data handler DL-B

PD.rsp PD.ind

CMD.ind

CMD.rsp

PDValid

System Management
PL_Mode.req Mode switch

DL_Mode

Device DL-mode handler

FHInfo CMD.ind CMD.rsp

Frame handler
PL_Transfer.ind PL_Transfer.req

DL_PDCycle

DL_Control

DL_ReadParam

DL_WriteParam

DL_ISDUTransport

DL_ISDUAbort

DL_EventTrigger

DL_Event

DL-A

SIO DI / DO

PL_WakeUp.ind

Wake-up

Coded switching

Switching signal

2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178

Physical Layer

Figure 74 Structure and services of the system management (Device) The System Management (SM) of the Device provides the central controlling instance via the Line Handler through all the phases of initialization, default state (SIO), communication startup, communication, and fall-back to SIO mode. The Device SM interacts with the PL to establish the necessary line driver and receiver adjustments (Figure 14), with the DL to get the necessary information from the Master (wakeup, transmission rates, a.o.) and with the Device applications to ensure the Device identity and compatibility (identification parameters). The transitions between the line handler states (Figure 76) are initiated by the Master port activities (wake-up and communication) and triggered through the Device Data Link Layer via the DL_Mode indications and DL_Write requests (commands). The SM provides the Device identification parameters through the Device applications interface. The sequence chart in Figure 75 demonstrates a typical Device sequence from initialization to default SIO mode and via wake-up request from the Master to final communication. The sequence chart is complemented by the use case of a communication error such as T DSIO expired, or communication fault, or a request from Master (event) such as Fallback.

61131-9/WD V0.5 IEC

PL DL

127
SM Device App

Working Draft

SM_SetDeviceMode(IDLE) PL_SetMode(INACTIVE) SM_DeviceMode(IDLE) SM_SetDeviceCom(Initial parameter) SM_SetDeviceIdent(Initial parameter) PL_SetMode(DI | DO | INACTIVE) SM_SetDeviceMode(SIO) SM_DeviceMode(SIO) SIO mode active PL_WakeUp(ind) DL_Mode(STARTUP) PL_SetMode(COMx) SM_DeviceMode(COMSTARTUP) Errors /events - Tdsio expired - Fallback Communication startup and data exchange Device default communication and identification parameter

WakeUp request from master

DL_Mode(INACTIVE) PL_SetMode(INACTIVE)

SM_DeviceMode(IDLE) SM_SetDeviceCOM(Initial parameter) SM_SetDeviceIdent(Initial parameter) SM_SetDeviceMode(SIO) PL_SetMode(DI | DO | INACTIVE) SM_DeviceMode(SIO) SIO mode active

2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 9.3.2 9.3.2.1 SM Device services Overview Figure 75 Sequence chart of the use case "INACTIVE SIO SDCI SIO" The SM services shown in Figure 75 are defined in the subsequent sections.

This section describes the services the Device system management provides to its applications as shown in Figure 74. Table 80 lists the assignment of the Device to its role as initiator or receiver for the individual system management service.

Working Draft 2189

128 Table 80 SM services within the Device

Service name SM_SetDeviceCom SM_GetDeviceCom SM_SetDeviceIdent SM_GetDeviceIdent SM_SetDeviceMode SM_DeviceMode Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service Device R R R R R I

61131-9/WD V0.5 IEC

2190 2191 2192 2193 2194 2195 9.3.2.2 SM_SetDeviceCom

The SM_SetDeviceCom service is used to configure the communication properties supported by the Device in the System Management. The parameters of the service primitives are listed in Table 81. Table 81 SM_SetDeviceCom
Parameter name Argument ParameterList M M .req .cnf

Result (+)

Result (-) ErrorInfo

S M

2196 2197 2198 2199 2200 2201 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2214

Argument The service-specific parameters of the service request are transmitted in the argument. ParameterList This parameter specifies the configured communication parameters for a Device. Parameter type: Record Record Elements: SupportedSIOMode This parameter specifies the SIO mode supported by the Device. Permitted values: INACTIVE, DI, DO SupportedBaudrate This parameter specifies the transmission rates supported by the Device. Permitted values: COM1, COM2, COM3 MinCycleTime This parameter specifies the minimum cycle time supported by the Device (B.1.4). F-sequence Capability This parameter specifies the F-sequence capabilities supported by the Device (B.1.5): - ISDU support

61131-9/WD V0.5 IEC 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2226 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 9.3.2.3 SM_GetDeviceCom

129

Working Draft

- OPERATE F-sequence types - PREOPERATE F-sequence types RevisionID (RID) This parameter specifies the protocol revision RID (B.1.6) supported by the Device. ProcessDataIn This parameter specifies the length of process data to be sent to the Master (B.1.7). ProcessDataOut This parameter specifies the length of process data to be sent by the Master (B.1.8). Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: STATE_CONFLICT

The SM_GetDeviceCom service is used to read the current communication properties from the System Managment. The parameters of the service primitives are listed in Table 82. Table 82 SM_GetDeviceCom
Parameter name Argument ParameterList M M .req .cnf

Result (+)

Result (-) ErrorInfo

S M

2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250

Argument The service-specific parameters of the service request are transmitted in the argument. ParameterList This parameter specifies the configured communication parameter for a Device. Parameter type: Record Record Elements: CurrentMode This parameter specifies the current SIO or Communication Mode by the Device. Permitted values: INACTIVE, DI, DO, COM1, COM2, COM3 MasterCycleTime This parameter keeps the MasterCycleTime to be set by the Master system management (B.1.3). This parameter is only valid in the state SM_Operate. F-sequence Capability

Working Draft 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276

130

61131-9/WD V0.5 IEC

This parameter specifies the current F-sequence capabilities configured in the system management of the Device ( B.1.5). - ISDU support - OPERATE F-sequence types - PREOPERATE F-sequence types RevisionID (RID) This parameter contains the current protocol revision RID (B.1.6) within the system management of the Device. ProcessDataIn This parameter provides the current length of process data to be sent to the Master (B.1.7). ProcessDataOut This parameter provides the current length of process data to be sent by the Master (B.1.8). Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: STATE_CONFLICT 9.3.2.4 SM_SetDeviceIdent

The SM_SetDeviceIdent service is used to configure the Device identification data in the System Management. The parameters of the service primitives are listed in Table 83. Table 83 SM_SetDeviceIdent
Parameter name Argument ParameterList M M .req .cnf

Result (+)

Result (-) ErrorInfo

S M

2277 2278 2279 2280 2281 2282 2283 2284 2285 2286 2287 2288

Argument The service-specific parameters of the service request are transmitted in the argument. ParameterList This parameter specifies the configured identification parameter for a Device. Parameter type: Record Record Elements: VendorID (VID) This parameter specifies the VendorID assigned to a Device (B.1.9) Data length: 2 octets DeviceID (DID) This parameter specifies one of the assigned DeviceIDs (B.1.10) Data length: 3 octets

61131-9/WD V0.5 IEC 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302

131

Working Draft

FunctionID (FID) This parameter specifies one of the assigned FunctionIDs (see clause B.1.11). Data length: 2 octets Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: STATE_CONFLICT 9.3.2.5 SM_GetDeviceIdent

The SM_GetDeviceIdent service is used to read the Device identification parameter from the System Management. The parameters of the service primitives are listed in Table 84. Table 84 SM_GetDeviceIdent
Parameter name Argument ParameterList M M .req .cnf

Result (+)

Result (-) ErrorInfo

S M

2303 2304 2305 2306 2307 2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318 2319 2320 2321 2322 2323

Argument The service-specific parameters of the service request are transmitted in the argument. ParameterList This parameter contains the configured communication parameters of the Device. Parameter type: Record Record Elements: VendorID (VID) This parameter contains the actual VendorID of the Device (B.1.9) Data length: 2 octets DeviceID (DID) This parameter contains the actual DeviceID of the Device (B.1.10) Data length: 3 octets FunctionID (FID) This parameter contains the actual FunctionID of the Device (B.1.11). Data length: 2 octets Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request failed. ErrorInfo

Working Draft 2324 2325 2326 2327 2328 2329

132

61131-9/WD V0.5 IEC

This parameter contains error information to supplement the Result parameter. Permitted values: STATE_CONFLICT 9.3.2.6 SM_SetDeviceMode

The SM_SetDeviceMode service is used to set the Device into a defined operational state during initialization. The parameters of the service primitives are listed in Table 85. Table 85 SM_SetDeviceMode
Parameter name Argument Mode M M .req .cnf

Result (+)

Result (-) ErrorInfo

S M

2330 2331 2332 2333 2334 2335 2336 2337 2338 2339 2340 2341 2342 2343 2344 2345

Argument The service-specific parameters of the service request are transmitted in the argument. Mode Permitted values: IDLE, SIO Result (+): This selection parameter indicates that the service request has been executed successfully. Result (-): This selection parameter indicates that the service request failed. ErrorInfo This parameter contains error information to supplement the Result parameter. Permitted values: STATE_CONFLICT 9.3.2.7 SM_DeviceMode

The SM_DeviceMode service is used to indicate changes of communication states to the Device application. The parameters of the service primitives are listed in Table 86. Table 86 SM_DeviceMode
Parameter name Argument Mode M M .ind

2346 2347 2348 2349 2350 2351 2352

Argument The service-specific parameters of the service request are transmitted in the argument. Mode Permitted values: IDLE, SIO, COM_STARTUP, COM1, COM2, COM3, IDENT_STARTUP, IDENT_CHANGE, PREOPERATE, OPERATE

61131-9/WD V0.5 IEC 2353 2354 2355 2356 2357 2358 2359 9.3.3 9.3.3.1 SM Device protocol Overview

133

Working Draft

The behaviour of the Device is mainly driven by Master messages. 9.3.3.2 SM Device state machine

Figure 76 shows the SM line handler state machine of the Device. It is triggered by the DL_Mode handler and the Device application. It evaluates the different communication phases during startup and controls the line state of the Device.

/Initialization SM_Idle_0 SM_DeviceMode_SIO/ T1 SM_SIO_1

DL_Mode_STARTUP/ T2 SM_ComEstabl_2

DL_Mode_INACTIVE/ T3

DL_Mode_COMx/ T4

DL_Mode_STARTUP/ T13 DL_Mode_STARTUP/ T12

SM_ComStartup_3

DL_Mode_OPERATE/ T11

DL_Write_MASTERIDENT/ T5 DL_Mode_PREOPERATE/ T10

SM_IdentStartup_4

DL_Write_DEVICEIDENT/ T6 SM_IdentCheck_5

DL_Read_COMMAND/ T7

SM_CompStartup_6

DL_Mode_PREOPERATE/ T8 SM_Preoperate_7

DL_Mode_OPERATE/ T9 SM_Operate_8

2360 2361 2362 2363 Figure 76 State machine of the Device system management Table 87 describes the individual states and the actions within the transitions. Table 87 State transition tables of the Device system management
STATE NAME STATE DESCRIPTION

Working Draft
STATE NAME SM_Idle_0

134
STATE DESCRIPTION

61131-9/WD V0.5 IEC

In SM_Idle the SM is waiting for configuration by the Device application and to be set to SIO mode. The state is left on receiving a SM_SetDeviceMode(SIO) request from the Device application The following sequence of services shall be executed between Device application and SM. SM_SetDeviceCom(initial parameter list) SM_SetDeviceIdent(VID, initial DID, FID)

SM_SIO_1

In SM_SIO the SM Line Handler is remaining in the default SIO mode. The Physical Layer is set to the SIO mode characteristics defined by the Device application via the SetDeviceMode service. The state is left on receiving a DL_Mode(STARTUP) indication. In SM_ComEstablish the SM is waiting for the communication to be established in the Data Link Layer. The state is left on receiving a DL_Mode(INACTIVE) or a DL_Mode(COMx) indication, where COMx may be any of COM1, COM2 or COM3. In SM_ComStartup the communication parameter (DP 02h to 06h) are read by the Master SM via DL_Read requests. The state is left on receiving a DL_Mode(INACTIVE), a DL_Mode(OPERATE) indication (Master V1.0 only) or a DL_Write(MASTERIDENT) request (Master >V1.0). In SM_IdentStartup the identification data (VID, DID, FID) are read and verified by the Master. In case of incompatibilities the Master SM writes the supported SDCI Revision (RID) and configured DeviceID (DID) to the Device. The state is left on receiving a DL_Mode(INACTIVE), a DL_Mode(PREOPERATE) indication (compatibility check passed) or a DL_Write(DEVICEIDENT) request (new compatibility requested). In SM_IdentCheck the SM waits for new initialization of communication and identification parameters. The state is left on receiving a DL_Mode(INACTIVE) indication or a DL_Read(DP 02h) request. Within this state the Device application shall check the RID and DID parameters from the SM and set these data to the supported values. Therefore the following sequence of services shall be executed between Device application and SM. SM_GetDeviceCom(configured RID, parameter list) SM_GetDeviceIdent(configured DID, parameter list) Device application checks and provides compatibility function and parameters SM_SetDeviceCom(new supported RID, new parameter list) SM_SetDeviceIdent(new supported DID, parameter list)

SM_ComEstablish_2

SM_ComStartup_3

SM_IdentStartup_4

SM_IdentCheck_5

SM_CompStartup_6

In SM_CompatStartup the communication and identification data are reread and verified by the Master SM. The state is left on receiving a DL_Mode(INACTIVE) or a DL_Mode(PREOPERATE) indication. During SM_Preoperate the the SerialNumber can be read and verified by the Master SM, as well as data storage and Device parameterization may be executed. The state is left on receiving a DL_Mode(INACTIVE), a DL_Mode(STARTUP) or a DL_Mode(OPERATE) indication. During SM_Operate the cyclic process data exchange and acyclic On-Request data transfer are active. The state is left on receiving a DL_Mode(INACTIVE) or a DL_Mode(STARTUP) indication.

SM_Preoperate_7

SM_Operate_8

2364
TRANSITION T1 SOURCE STATE 0

TARGET STATE 1

ACTION The Device is switched to the configured SIO mode by receiving the trigger SM_SetDeviceMode.req(SIO). PL_SetMode(DI|DO|INACTIVE) SM_DeviceMode(SIO) The Device is switched to the communication mode by receiving the trigger DL_Mode.ind(STARTUP). PL_SetMode(COMx) SM_DeviceMode(COMSTARTUP) The Device is switched to SM_Idle mode by receiving the trigger DL_Mode.ind(INACTIVE) . PL_SetMode(INACTIVE) SM_DeviceMode(IDLE) The Device is leaving the state by receiving the trigger DL_Mode.ind(INACTIVE).

T2

T3

2,3,4,5,6, 7,8

T4

The Device application receives an indication on the baudrate with which the communication has been established in the DL triggered by DL_Mode.ind(COMx).

61131-9/WD V0.5 IEC

TRANSITION SOURCE STATE TARGET STATE

135
ACTION SM_DeviceMode(COMx)

Working Draft

T5

The Device identification phase is entered by receiving the trigger DL_Write.ind(MASTERIDENT). SM_DeviceMode(IDENTSTARTUP) The Device identity check phase is entered by receiving the trigger DL_Write.ind(DEVICEIDENT). SM_DeviceMode(IDENTCHANGE) The Device compatibility startup phase is entered by receiving the trigger DL_Read.ind( Direct Parameter page 1, 0x02). The Device's preoperate phase is entered by receiving the trigger DL_Mode.ind(PREOPERATE). SM_DeviceMode(PREOPERATE) The Device's operate phase is entered by receiving the trigger DL_Mode.ind(OPERATE). SM_DeviceMode(OPERATE) The Device's preoperate phase is entered by receiving the trigger DL_Mode.ind(PREOPERATE). SM_DeviceMode(PREOPERATE) The Device's operate phase is entered by receiving the trigger DL_Mode.ind(OPERATE). SM_DeviceMode(OPERATE) The Device's communication startup phase is entered by receiving the trigger DL_Mode.ind(STARTUP). SM_DeviceMode(COM_STARTUP) The Device's communication startup phase is entered by receiving the trigger DL_Mode.ind(STARTUP). SM_DeviceMode(COM_STARTUP) TYPE DEFINITION Any of COM1, COM2, or COM3 transmission rates

T6

T7 T8

5 6

6 7

T9

T10

T11

T12

T13

2365
INTERNAL ITEMS COMx Variable

2366 2367 2368 Figure 77 shows a typical sequence chart for the SM communication startup of a Device matching the Master port configuration settings (regular startup).

Working Draft
DL AL

136
SM

61131-9/WD V0.5 IEC

Device App

DL_Mode(COMx) SM_DeviceMode(COMx) DL_Read(Direct Parameter 1) (MinCycleTime, FrameCapability, RID, PDin length, PDout length) Master actions (optional): - Check RID, VID, DID, FID (Use case assumes: check OK) DL_Write(0x00, MASTERIDENT) SM_DeviceMode(IDENTSTARTUP)

DL_Read(Direct Parameter 1) (VID,DID,FID) From now on: PREOPERATE state SM_DeviceMode(PREOPERATE)

DL_Write(0x00, PREOPERATE)

Master actions (optional): - Read Serial Number - Data Storage - User parameterization

DL_SPDUTransport() (As many as needed) AL_Read() (As many AL_Read and AL_Write as needed)

...
DL_SPDUTransport()

...
AL_Read()

DL_Write(0x01, MasterCycleTime) DL_Write(0x00, OPERATE) SM_DeviceMode(OPERATE)

From now on: OPERATE state

2369 2370 2371 2372 2373 2374 2375 2376 Figure 77 Sequence chart of a regular Device startup Figure 78 shows a typical sequence chart for the SM communication startup of a Device not matching the Master port configuration settings (compatibility mode). In this mode, the Master tries to overwrite the Device's identification parameters to achieve a compatible and a workable mode. The sequence chart in Figure 78 shows only the actions until the PREOPERATE state. The remaining actions until the OPERATE state can be taken from Figure 77.

61131-9/WD V0.5 IEC

DL

137
SM Device App

Working Draft

DL_Mode(COMx) SM_DeviceMode(COMx) DL_Read(Direct Parameter 1) (MinCycleTime, FrameCapability, RID, PDin length, PDout length) Master actions: - Check RID, VID, DID, FID (Use case assumes: check DID or RID fails) DL_Write(0x00, MASTERIDENT) SM_DeviceMode(IDENTSTARTUP)

DL_Read(Direct Parameter 1) (VID,DID,FID)

DL_Write(0x04, CRID) DL_Write(0x09...0x0B, CDID) DL_Write(0x00, DEVICEIDENT) Master action: - Wait one cycle DL_Read(Direct Parameter 1) (MinCycleTime, FrameCapability, RID, PDin length, PDout length) DL_Write(0x00, MASTERIDENT) DL_Read(Direct Parameter 1) (VID,DID,FID) SM_DeviceMode(IDENTSTARTUP) SM_DeviceMode(IDENTCHANGE) SM_SetDeviceCOM(compatible parameter) SM_SetDeviceIdent(compatible DID, FID)

Device compatibility check: - supported RID - supported DID

Master actions: - Check RID, VID, DID, FID (Use case assumes: check OK)

From now on: PREOPERATE state DL_Write(0x00, PREOPERATE) SM_DeviceMode(PREOPERATE)

...

...

2377 2378 2379 2380 2381 2382 Figure 78 Sequence chart of a Device startup in compatibility mode Figure 79 shows a typical sequence chart for the SM communication startup of a Device not matching the Master port configuration settings. The System Management of the Master tries to reconfigure the Device with alternative Device identification parameters (compatibility mode). In this use case, the alternative parameters are assumed to be incompatible.

Working Draft
DL

138
SM

61131-9/WD V0.5 IEC

Device App

DL_Mode(COMx) SM_DeviceMode(COMx) DL_Read(Direct Parameter 1) (MinCycleTime, FrameCapability, RID, PDin length, PDout length) Master actions: - Check RID, VID, DID, FID (Use case assumes: check DID or RID fails) DL_Write(0x00, MASTERIDENT) SM_DeviceMode(IDENTSTARTUP)

DL_Read(Direct Parameter 1) (VID,DID,FID)

DL_Write(0x04, CRID) DL_Write(0x09...0x0B, CDID) DL_Write(0x00, DEVICEIDENT) Master action: - Wait one cycle DL_Read(Direct Parameter 1) (MinCycleTime, FrameCapability, RID, PDin length, PDout length) DL_Write(0x00, MASTERIDENT) DL_Read(Direct Parameter 1) (VID,DID,FID) SM_DeviceMode(IDENTSTARTUP) SM_DeviceMode(IDENTCHANGE) SM_SetDeviceCOM(supported parameter) SM_SetDeviceIdent(supported DID, FID)

Device compatibility check: - not supported RID - not supported DID

Master actions: - Check RID, VID, DID, FID (Use case assumes: check DID or RID fails)

...
2383 2384 2385

...

Figure 79 Sequence chart of a Device startup when compatibility fails

61131-9/WD V0.5 IEC

139

Working Draft

2386 2387 2388

10 Device
10.1 Overview

Figure 80 provides an overview of the complete structure and services of a Device.

Device applications Technology specific application (technology parameter, diagnosis, process data) Parameter Manager (PM) Data Storage (DS) Event Dispatcher (ED) Process Data Exchange (PDE)
AL_NewOutput AL_GetOutput

AL_Write

AL_Abort

AL_Read

AL_PDCycle

AL_SetInput

AL_Control

AL_Event

SIO: DI / DO

SM_GetDeviceComm

SM_SetDeviceComm

SM_SetDevciceIdent

SM_GetDeviceIdent

SM_SetDeviceMode

SM_DeviceMode

On-request data AL objects Application Layer

DL_PDInputUpdate DL_Control DL_EventTrigger

Process data objects

DL_PDOutputTransport DL_PDCycle

DL_ReadParam

DL_WriteParam

DL_ISDUTransport

DL_ISDUAbort

Line Handler

On-request data handler

EventFlag

DL_Event

Process data handler DL-B

PD.ind PD.rsp

CMD.rsp

CMD.ind

DL_Read DL_Write

PDValid

DL-A

System management
PL_Mode.req Mode switch

DL_Mode

Device DL-mode handler

FHInfo CMD.ind CMD.rsp

Frame handler
PL_Transfer.ind PL_Transfer.req SIO: DI / DO

PL_WakeUp.ind

Wake-up

Coded switching

Switching signal

2389 2390 2391 2392 2393 2394 2395 2396 2397 2398 2399 2400 2401 2402 2403 2404 2405

Physical layer

Figure 80 Structure and services of a Device The Device applications comprise first the technology specific application consisting of the transducer with its technology parameters, its diagnosis information, and its process data. The common Device applications comprise a Parameter Manager (PM), dealing with compatibility and correctness checking of complete sets of technology (vendor) specific and common system parameters (see 10.3), and a Data Storage (DS) mechanism, which optionally uploads or downloads parameters to the Master (see 10.4), and a Event Dispatcher (ED), supervising states and conveying diagnosis information such as notifications, warnings, errors, and Device requests as peripheral initiatives (see 10.5), and a Process Data Exchange (PDE) unit, conditioning the data structures for transmission in case of a sensor or preparing the received data structures for signal generation. It also controls the operational states to ensure the validity of process data (see 10.2).

These Device applications provide standard methods/functions and parameters common to all Devices, and Device specific functions and parameters, all specified within this clause.

Working Draft 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2433 2434 2435 2436 2437 2438 2439 2440 2441 2442 2443 2444 2445 2446 2447 2448 2449 2450 10.2 Process Data Exchange (PDE)

140

61131-9/WD V0.5 IEC

The Process Data Exchange unit cyclically transmits and/or receives process data without interference with the on-request data (parameters, commands, and events). An actuator (output Process Data) shall observe the cyclic transmission and enter a default state, for example keep last value, stop, or de-energize, when the data transmission is interrupted. The actuator shall wait on the MasterCommand "ProcessDataOutputOperate" (Table B.2) prior to regular operation after restart in case of interruption. If communication is not interrupted, an actuator (output Process Data) will receive a MasterCommand "DeviceOperate", whenever the output Process Data are invalid and a MasterCommand "ProcessDataOutputOperate" whenever they become valid again (Table B.2). There is no need for a sensor Device (input Process Data) to observe the cyclic transmission. However, if the Device is not able to guarantee valid process data, the "PD invalid" flag (A.1.5) shall be signaled to the Master application. 10.3 10.3.1 Parameter Manager (PM) General

A Device can be parameterized via two basic methods using the Direct Parameters or the Index memory space accessible with the help of ISDUs (Figure 4). Mandatory for all Devices are the so-called Direct Parameters in page 1. This page 1 contains common communication and identification parameters (B.1). Direct Parameter page 2 optionally offers space for a maximum of 16 octets of technology (vendor) specific parameters for Devices requiring not more than this limited number and with small system footprint (ISDU communication not implemented, easier fieldbus handling possible but with less comfort). Access to the Direct Parameter page 2 is performed via AL_Read and AL_Write (10.7.4). The transmission of parameters to and from the spacious Index memory is secured by an additional checksum and confirmation of the transmitted parameters. This confirmation comprises consistency and validity of the entire parameter set. A negative acknowledgement contains an appropriate error description. In this case the transmitted parameters shall be rejected and a roll back to the previous parameter set shall be performed to ensure proper functionality of the Device. 10.3.2 Parameter Manager state machine

The Device can be parameterized using ISDU mechanisms whenever the PM is active. The main functions of the PM are the transmission of parameters to the Master ("Upload"), to the Device ("Download"), and the consistency and validity checking within the Device ("ValidityCheck") as demonstrated in Figure 81. The PM is driven by command messages of the Master (Table B.8). For example the guard [UploadStart] corresponds to the reception of the SystemCommand "ParamUploadStart" and [UploadEnd] to the reception of the SystemCommand "ParamUploadEnd". In case of a communication interruption, the Master system management uses the service SM_DeviceMode with the variable "INACTIVE" to stop the upload process and to return to the "IDLE" state. Any new "ParamUploadStart" or "ParamDownloadStart" while another sequence is pending, for example due to an unexpected shut-down of a vendor parameterization tool, will abort the pending sequence. The corresponding parameter changes will be discarded.
NOTE A PLC user program and a parameterization tool can conflict (multiple access). For example during commissioning: the user should disable accesses from the PLC program while changing parameters via the tool.

61131-9/WD V0.5 IEC 2451 2452

141

Working Draft

The Parameter Manager mechanism in a Device is always active and the DS_ParUpload.req in transition T4 is used to trigger the Data Storage (DS) mechanism in 10.4.2.

/Initialization

[Single Parameter]/T1 [DownloadStore]/T2 [Local Parameter]/T3

Idle_0

[DownloadStart]/ T16

[DownloadStart]/T7

[DataValid & StoreRequest]/T4 ValidityCheck_1 [DataValid & NotStoreRequest]/T5 [DataInvalid]/T6

[DownloadBreak]/T8 Download_2 SM_DeviceMode_INACTIVE/ T9

[UploadStart]/ T10 SM_DeviceMode_INACTIVE/ T12 Upload_3

[UploadEnd]/ T11

[DownloadEnd]/T13 [DownloadStore]/ T14

[UploadStart]/T15

2453 2454 2455 2456 2457

STATE NAME Idle_0 ValidityCheck_1 Download_2 Upload_3

Figure 81 The Parameter Manager (PM) state machine Table 88 shows the state transition tables of the Device Parameter Manager (PM) state machine. Table 88 State transition tables of the PM state machine
STATE DESCRIPTION Waiting on parameter transmission Check of consistency and validity of current parameter set. Parameter download active; local parameterization locked (e.g. teach-in) Parameter upload active; parameterization globally locked; all write accesses for parameter changes via tools shall be rejected (ISDU ErrorCode "Service temporarily not available Device control") SOURCE STATE 0 0 0 1 1 1 0 2 TARGET STATE 1 1 1 0 0 0 2 0 Set "StoreRequest" (= TRUE) Set "StoreRequest" (= TRUE) Mark parameter set as valid; send DS_ParUpload.req to DS; enable positive acknowledge of transmission; reset "StoreRequest" (= FALSE) Mark parameter set as valid; enable positive acknowledge of transmission Mark parameter set as invalid; enable negative acknowledge of transmission; reset "StoreRequest" (= FALSE) Lock local parameter access Unlock local parameter access; discard parameter buffer ACTION

2458
TRANSITION T1 T2 T3 T4 T5 T6 T7 T8

Working Draft
TRANSITION T9 T10 T11 T12 T13 T14 T15 SOURCE STATE 2 0 3 3 2 2 3 2 TARGET STATE 0 3 0 0 1 1 3 2 TYPE Bool Bool Bool Bool Bool Bool Bool Bool Bool Bool

142
ACTION

61131-9/WD V0.5 IEC

Unlock local parameter access; discard parameter buffer Lock local parameter access Unlock local parameter access Unlock local parameter access Unlock local parameter access Unlock local parameter access; set "StoreRequest" (= TRUE) Unlock local parameter access; discard parameter buffer Hint: A possible second start cannot be blocked. DEFINITION SystemCommand "ParamDownloadStore" received, see Table B.8 Positive result of conformity and validity checking Negative result of conformity and validity checking SystemCommand "ParamDownloadStart" received, see Table B.8 SystemCommand "ParamBreak" or "ParamUploadStart" received SystemCommand "ParamDownloadEnd" received, see Table B.8 Flag for a requested Data Storage sequence, i.e. SystemCommand "ParamDownloadStore" received (= TRUE) Inverted value of StoreRequest SystemCommand "ParamUploadStart" received, see Table B.8 SystemCommand "ParamUploadEnd" received, see Table B.8

2459

T16

INTERNAL ITEMS DownloadStore DataValid DataInvalid DownloadStart DownloadBreak DownloadEnd StoreRequest NotStoreRequest UploadStart UploadEnd

2460 2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475

The Parameter Manager (PM) allows for single parameter (Index and Subindex) as well as for block parameter transmission (entire parameter set). 10.3.3 Dynamic parameter

Parameters accessible through SDCI read or write services may as well be changed via onboard control elements (for example teach-in button) or the human machine interface of a Device. These changes shall undergo the same validity checks as compared to a single parameter access. Thus, in case of a positive result "DataValid" in Figure 81, the "StoreRequest" flag shall be applied in order to achieve Data Storage consistency. In case of a negative result "InvalidData", the previous values of the corresponding parameters shall be restored ("roll back"). In addition, a Device specific indication on the human machine interface can be made available as a positive or negative feedback to the user. It is recommended to avoid concurrent access to a parameter via local control elements and SDCI write services at the same point in time. 10.3.4 Single parameter

Sample sequence charts for valid and invalid single parameter changes are described in Figure 82.

61131-9/WD V0.5 IEC

Master App Master AL

143
Device AL Device App

Working Draft

AL_Write_req(Parameter) SDCI_Message()

AL_Write_ind(Parameter) AL_Write_res(+) SDCI_Message()

Parameter check result = OK

AL_Write_cnf(+)

Positive result
AL_Write_req(Parameter) SDCI_Message()

Negative result

AL_Write_ind(Parameter) AL_Write_res(-) SDCI_Message()

Parameter check failed

AL_Write_cnf(-)

2476 2477 2478 2479 2480 2481 2482

Parameter check Access

Figure 82 Positive and negative parameter checking result If single parameterization is performed via ISDU objects, the Device shall check the access, structure, consistency and validity (Table 89) of the transmitted data within the context of the entire parameter set and return the result in the confirmation. The negative confirmation carries one of the error indications of Table C.2 in Annex C. Table 89 Definitions of parameter checks
Definition Check for valid access rights for this Index / Subindex, independent from data content (Index / Subindex permanent or temporarily unavailable; write access on read only Index) Check for valid data content of the entire parameter set, testing for interference or correlations between parameters Check for valid data structure like data size, only complete data structures can be written, for example 2 octets to an UInteger16 data type Check for valid data content of single parameters, testing for data limits Error indication See C.2.3C.2.8

Consistency

See C.2.16 and C.2.17

Structure

See C.2.12 and C.2.13

Validity

See C.2.9C.2.11, C.2.14, C.2.15

2483 2484 2485 2486 2487 10.3.5 Block parameter

User applications such as function blocks within PLCs and parameterization tool software can use start and end commands to indicate the begin and end of a block parameter transmission. For the duration of the block parameter transmission the Device application shall inhibit all the

Working Draft 2488 2489 2490 2491

144

61131-9/WD V0.5 IEC

parameter changes originating from other sources, for example local parameterization, teachin, etc. A sample sequence chart for valid block parameter changes with an optional Data Storage request is demonstrated in Figure 83.
Master App Master AL Device AL Device App

AL_Write_req(SysCommand) (ParamDownloadStart) SDCI_Message()

AL_Write_ind(SysCommand) (ParamDownloadStart) AL_Write_res(+) SDCI_Message()

AL_Write_cnf(+) AL_Write_req(Parameter) SDCI_Message()

AL_Write_ind(Parameter) AL_Write_res(+) SDCI_Message()

AL_Write_cnf(+)

More parameter sequences as needed

AL_Write_req(SysCommand) (ParamDownloadStore) SDCI_Message()

AL_Write_ind(SysCommand) (ParamDownloadStore) AL_Write_res(+) SDCI_Message() DS_ParUpload_req() AL_Write_cnf(+)

Parameter check result = OK

Option: Data storage upload request

2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 Figure 83 Positive block parameter download with Data Storage request A block parameter transmission is aborted if the Parameter Manager receives a SystemCommand "ParamBreak". In this case the block transmission quits without any changes in parameter settings. The "ParamUploadStart" command (Table B.8) indicates the beginning of the block parameter transmission in upload direction (from the Device to the user application). The SystemCommand "ParamUploadEnd" terminates this sequence and indicates the end of transmission. A sample sequence chart for invalid block parameter changes is demonstrated in Figure 84.

61131-9/WD V0.5 IEC

Master App Master AL

145
Device AL Device App

Working Draft

AL_Write_req(SysCommand) (ParamDownloadStart) SDCI_Message()

AL_Write_ind(SysCommand) (ParamDownloadStart) AL_Write_res(+) SDCI_Message()

AL_Write_cnf(+) AL_Write_req(Parameter) SDCI_Message()

AL_Write_ind(Parameter) AL_Write_res(+) SDCI_Message()

AL_Write_cnf(+)

More parameter sequences as needed

AL_Write_req(SysCommand) (ParamDownloadEnd or ParamDownloadStore)

SDCI_Message()

AL_Write_ind(SysCommand) (ParamDownloadEnd or ParamDownloadStore) AL_Write_res(-) SDCI_Message()

Parameter check failed

AL_Write_cnf(-)

2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 Figure 84 Negative block parameter download The "ParamDownloadStart" command (Table B.8) indicates the beginning of the block parameter transmission in download direction (from user application to the Device). The SystemCommand "ParamDownloadEnd" or "ParamDownloadStore" terminates this sequence. Both functions are similar. However, in addition the SystemCommand "ParamDownloadStore" causes the Data Storage (DS) mechanism to upload the parameter set through the DS_UPLOAD_REQ Event (10.4.2).During block parameter download the consistency checking for single transferred parameters shall be disabled and the parameters are not activated. With the "ParamDownloadEnd" command, the Device checks the entire parameter set and indicates the result to the originator of the block parameter transmission within the ISDU acknowledgement in return to the command. During the block parameter download the access and structure checks are always performed (Table 89). Optionally, validity checks can be performed also. The block transfer mode shall not be exited by the Device in case of invalid accesses or structure violations. In case of an invalid parameter set the changed parameters shall be discarded and and a rollback to the previous parameter set shall be performed. The corresponding negative confirmation shall contain one of the error indications from Table C.2 in Annex C. With a

Working Draft 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538 2539 2540 2541 2542 2543 2544 2545 2546 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558

146

61131-9/WD V0.5 IEC

negative confirmation of the SystemCommand "ParamDownloadStore", the data storage upload request is omitted. 10.3.6 Concurrent parameterization access

There is no mechanism to secure parameter consistency within the Device in case of concurrent accesses from different user applications above Master level. This shall be ensured or blocked on user level. 10.3.7 Command handling

Application commands such as teach-in or restore factory settings are conveyed in form of parameters. An application command is confirmed with a positive service response AL_Write.res(+). A negative service response AL_Write.res(-) shall indicate the failed execution of the application command. In both cases the ISDU timeout limit shall be considered (Table 91). 10.4 10.4.1 Data Storage (DS) General

The Data Storage (DS) mechanism enables the consistent and up-to-date buffering of the Device parameters on upper levels like PLC programs or fieldbus parameter server. Data Storage between Masters and Devices is specified within this document, whereas the adjacent upper data storage mechanisms depend on the individual fieldbus or system. The Device holds a standardized set of objects providing information about parameters for data storage such as memory size requirements, control and state information of the Data Storage mechanism (Table B.9). Revisions of Data Storage parameter sets are identified via a Parameter Checksum. The implementation of the DS mechanism defined in this specification is highly recommended for Devices. If this mechanism is not supported it is the responsibility of the Device vendor to describe how parameterization of a Device after replacement can be ensured in a system conform manner without tools. 10.4.2 Data Storage state machine

Any changed set of valid parameters leads to a new Data Storage upload. The upload is initiated by the Device by raising a "DS_UPLOAD_REQ" event (Table D.2). The Device shall store the internal state "Data Storage Upload" in non-volatile memory (Table B.9, State Property), until it receives a Data Storage command "DS_UploadEnd" or "DS_DownloadEnd". The Device shall generate an event "DS_UPLOAD_REQ" (Table D.2) only if the parameter set is valid and parameters assigned for data storage have been changed locally on the Device (for example teach-in, human machine interface, etc.), or the Device receives a SystemCommand "ParamDownloadStore"

With this event information the Data Storage mechanism of the Master is triggered and initiates a data storage upload sequence. The state machine in Figure 85 illustrates the Device Data Storage mechanism.

61131-9/WD V0.5 IEC

147

Working Draft

/Inialization [Unlocked]/ T6 DS_ParUpload_ind/ T7 [Locked]/ T1 DS_ParUpload_ind/ T2

DSStateCheck_0

DSIdle_2

[Unlocked & not DS_UPLOAD_FLAG]/T3 [Unlocked & DS_UPLOAD_FLAG]/T4 [Locked]/T5

DSLocked_1

[TransmissionStart]/T8

[TransmissionEnd]/T9 [TranmissionBreak]/T10

DSActivity_3

2559 2560 2561 2562 Figure 85 The Data Storage (DS) state machine Table 90 shows the state transition tables of the Device Data Storage (DS) state machine. Table 90 State transition table of the Data Storage state machine
STATE NAME DSStateCheck_0 DSLocked_1 DSIdle_2 STATE DESCRIPTION Check activation state after initialization Waiting on data storage state machine to become unlocked Waiting on data storage activities Provide parameter set; local parameterization locked. SOURCE STATE 0 1 1 1 2 0 2 2 3 TARGET STATE 1 1 2 2 1 2 2 3 2 ACTION Set State_Property = "Data storage access locked" (Table B.9) Set DS_UPLOAD_FLAG = TRUE (Table B.9) Set State_Property = "Inactive" (Table B.9) Cast AL_EVENT.req (EventCode: DS_UPLOAD_REQ), Set State_Property = "Inactive" (Table B.9) Set State_Property = "Data storage access locked" (Table B.9) Set State_Property = "Inactive" (Table B.9) Set DS_UPLOAD_FLAG = TRUE (Table B.9), cast AL_EVENT.req (EventCode: DS_UPLOAD_REQ) Lock local parameter access, set State_Property = "Upload" or "Download" (Table B.9) Set DS_UPLOAD_FLAG = FALSE, unlock local parameter access, Set State_Property = "Inactive" (Table B.9) Unlock local parameter access, Set State_Property = "Inactive" (Table B.9) TYPE Bool Bool Service DEFINITION Data Storage unlocked, see B.2.4 Data Storage locked, see B.2.4 Device internal service between PM and DS (Figure 81)

2563

DSActivity_3 TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9

T10

2564
INTERNAL ITEMS Unlocked Locked DS_ParUpload.ind

Working Draft
INTERNAL ITEMS TransmissionStart TransmissionEnd TransmissionBreak TYPE Bool Bool Bool

148
DEFINITION

61131-9/WD V0.5 IEC

DS_Command "DS_UploadStart" or "DS_DownloadStart" received, see Table B.9 DS_Command "DS_UploadEnd" or "DS_DownloadEnd" received, see Table B.9 SM_MODE_INACTIVE or DS_Command "DS_Break" received, see Table B.9

2565 2566 2567 The truncated sequence chart in Figure 86 illustrates the important communication sequences after the parameterization.
Master App Master AL Device AL Dev ice App

AL_ Write_i nd(SysComma nd) (ParamUplo adStart) Data storag e uplo ad requ est act ive

AL_ Event(DS_UPL OAD_ REQ) SDCI_Message() AL_ Event_ ind(DS _UPLO AD_RE Q)

AL_ Write_req(DS_ Comm and) (DS _Uploa dEnd o r DS_ Downlo adEnd ) SDCI_Message() AL_ Write_i nd(DS_ Comm and) (DS _Uploa dEnd o r DS_ Downlo adEnd ) AL_ Write_res(+) SDCI_Message() Data storag e requ est inactive

AL_ Write_cnf(+)

2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578 2579 10.4.3 Figure 86 Data Storage request message sequence DS configuration

The Data Storage mechanism inside the Device can be disabled via the Master, for example by a tool or a PLC program to avoid intensive communication during commissioning or system tests. See B.2.4 for further details. 10.4.4 DS memory space

To handle the requested data amount for Data Storage under any circumstances, the requested amount of indices to be saved and the required total memory space are given in the Data Storage Size parameter, see Table B.9. The required total memory space (including the structural information shall not exceed 2 048 octets (Annex F). The Data Storage mechanism of the Master shall be able to support this amount of memory per port.

61131-9/WD V0.5 IEC 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2621 2622 2623 10.4.5 DS Index_List

149

Working Draft

The Device is the "owner" of the DS Index_List (Table B.9). Its purpose is to provide all the necessary information for a Device replacement. The DS Index_List shall be fixed for any specific DeviceID. Otherwise the data integrity between Master and Device cannot be guaranteed. The Index List shall contain the termination marker ( Table B.9), if the Device does not support Data Storage (see 10.4.1). The required storage size shall be 0 in this case. 10.4.6 DS parameter availability

All indices listed in the Index List shall be readable and writeable between the SystemCommands "DS_UploadStart" or "DS_DownloadStart" and "DS_UploadEnd" or "DS_DownloadEnd" (Table B.9). If one of the Indices is rejected by the Device, the Data Storage Master will abort the up- or download with a SystemCommand "DS_Break". In this case no retries of the Data Storage sequence will be performed. 10.4.7 DS without ISDU

The support of ISDU transmission in a Device is a precondition for the Data Storage of parameters. Parameters in Direct Parameter page 2 cannot be saved and restored by the Data Storage mechanism. 10.4.8 DS parameter change indication

The Parameter_Checksum defined in Table B.9 is used as an indicator for changes in a parameter set. This standard does not require a specific mechanism for detecting parameter changes. A set of recommended methods is provided in the informative Annex J. 10.5 Event Dispatcher (ED)

Any of the Device applications can generate predefined system status information when SDCI operations fail or technology specific information (diagnosis) as a result from technology specific diagnostic methods. The Event Dispatcher turns this information into an event according to the definitions in A.6. The Event consists of an EventQualifier indicating the properties of an incident and an EventCode ID representing a description of this incident together with possible remedial measures. Table D.1 comprises a list of predefined IDs and descriptions for application oriented incidents. A range of IDs is reserved for technology specific (vendor) incidents. Table D.2 comprises a list of predefined IDs for SDCI specific incidents. Events are classified in "Errors", "Warnings", and "Notifications". See 10.9.2 for recommendations on how to assign these classifications and (11.5) how the Master is controlling and processing these events. All events provided at one point in time are acknowledged with one single command. Therefore the event acknowledgement may be delayed by the slowest acknowledgement from upper system levels. 10.6 10.6.1 Device features General

The following Device features are defined to a certain degree in order to achieve a common behavior. They are accessible via standardized or Device specific methods or parameters. 10.6.2 Device compatibility

This feature enables a Device to play the role of a previous Device revision. In the start-up phase the Master system management overwrites the Device's inherent DeviceID (DID) with the requested former DeviceID. The Device's technology application shall switch to the former

Working Draft 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665

150

61131-9/WD V0.5 IEC

functional sets or subsets assigned to this DeviceID. Device compatibility support is optional for a Device. 10.6.3 Protocol revision compatibility

This feature enables a Device ( V1.1) to adjust its protocol layers to a previous SDCI protocol version. In the start-up phase the Master ( V1.1) system management overwrites the Device's inherent protocol RevisionID (RID). Revision compatibility support is optional for a Device ( V1.1).
NOTE A Device ( V1.1) operates on a legacy Master (V1.0) according to [13].

10.6.4

Factory settings

This feature enables a Device to return to the original delivery status while communicating. In case the Data Storage flag has been set it shall be reset.
NOTE In this case an existing stored parameter set within the Master will be automatically downloaded into the Device after its start-up.

It is the vendor's responsibility to guarantee the correct function under any circumstances. The reset is triggered by the reception of the SystemCommand "Restore factory settings" (Table B.8). Reset to factory settings is optional for a Device. 10.6.5 Application reset

This feature enables a Device to reset the technology specific application. It is especially useful whenever a technology specific application has to be set to a predefined operational state without communication interruption and a shut-down cycle. The reset is triggered by the reception of a SystemCommand "Application reset" (Table B.8). Reset of the technology specific application is optional for a Device. 10.6.6 Device reset

This feature enables a Device to perform a "warm start". It is especially useful whenever a Device has to be reset to an initial state such as power-on. In this case communication will be interrupted. The warm start is triggered by the reception of a SystemCommand "Device reset" (Table B.8). Warm start is optional for a Device. 10.6.7 Visual SDCI indication

This feature indicates the operational state of the Device's SDCI interface. The indication of the SDCI mode is described in 10.9.3. Indication of the SIO mode is vendor specific and not covered by this definition. The function is triggered by the indication of the system management (within all states except SM_Idle and SM_SIO in Figure 76). SDCI indication is optional for a Device. 10.6.8 Parameter access locking

This feature enables a Device to globally lock or unlock write access to all writable Device parameters accessible via the SDCI interface (B.2.4). The locking is triggered by the reception of a system parameter "Device Access Locks" (Table B.7). The support for these functions is optional for a Device. 10.6.9 Data storage locking

Setting this lock will cause the "State_Property" in Table B.9 to switch to "Data Storage locked" and the Device not to send a DS_UPLOAD_REQ Event. The support for this function is mandatory for a Device if the Data Storage mechanism is implemented.

61131-9/WD V0.5 IEC 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 10.6.10 Device parameter locking

151

Working Draft

Setting this lock will disable overwriting Device parameters via on-board control or adjustment elements such as teach-in buttons ( B.2.4). The support of this function is optional for a Device. 10.6.11 Device user interface locking Setting this lock will disable the operation of on-board human machine interface displays and adjustment elements such as teach-in buttons on a Device (B.2.4). The support for this function is optional for a Device. 10.6.12 Offset time The offset time t offset is a parameter to be configured by the user (B.2.20). It determines the beginning of the Device's technology data processing in respect to the start of the F-sequence cycle, that means the beginning of the Master (port) message. The offset enables Data processing of a Device to be synchronized with the Master (port) cycle within certain limits Data processing of multiple Devices on different Master ports to be synchronized with one another Data processing of multiple Devices on different Master ports to run with a defined offset

Figure 87 illustrates the timing of messages in respect to the data processing in Devices.
tCYC
Device specific technology Port (Master)

toffset

Data processing

toffset

Data processing

Message

Message

Device

Message

Message

2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697

tframe

tidle

Figure 87 Cycle timing The offset time defines a trigger relative to the start of an F-sequence cycle. The support for this function is optional for a Device. 10.6.13 Data Storage concept The Data Storage mechanism in a Device allows to automatically save parameters in the Data Storage server of the Master and to restore them upon event notification. Data consistency is checked in either direction within the Master and Device. Data storage mainly focuses on configuration parameters of a Device set up during commissioning (10.4 and 11.3). The support of this function is optional for a Device. 10.6.14 Block Parameter The Block Parameter transmission feature in a Device allows transfer of parameter sets from a PLC program without validity checks of the single data objects. The validity check is performed at the end of the Parameter Block transmission. This function mainly focuses on

Working Draft 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731 2732 2733 2734 2735 2736 2737 2738 2739 2740

152

61131-9/WD V0.5 IEC

exchange of parameters of a Device to be set up at runtime (10.3). The support of this function is optional for a Device. 10.7 10.7.1 Device design rules and constraints General

In addition to the protocol definitions in form of state, sequence, activity, and timing diagrams some more rules and constraints are required to define the behavior of the Devices. An overview of the major protocol variables scattered all over the document are concentrated in one table with references. 10.7.2 Process data

The process communication channel transmits the cyclic process data without any interference of the on-request communication channels. Process data exchange starts automatically whenever the Device is switched into the OPERATE state via message from the Master. The format of the transmitted data is Device specific and varies from no data octets up to 32 octets in each communication direction. It is highly recommended to comply especially with the rules in E.3.3 and in [3]. It also should be considered that the data structures are not causing ineffective PLC programs. See A.1.5 for details on the indication of valid or invalid Process Data via a PDValid flag within cyclic data exchange. 10.7.3 Direct Parameter

The Direct Parameter page communication provides no handshake mechanism to ensure proper reception or validity of the transmitted parameters. The Direct Parameter page can only be accessed single octet by single octet (Subindex) or as a whole (16 octets). Therefore, the consistency of parameters larger than 1 octet cannot be guaranteed in case of single octet access. The parameters from the Direct Parameter page cannot be saved and restored via the Data Storage mechanism. 10.7.4 ISDU communication channel

The ISDU communication channel provides a powerful means for the transmission of parameters and commands (B.2). The following rules shall be considered when using this channel (see Figure 5). Index 0 is not accessible via the ISDU communication channel. The access is redirected by the Master to the Direct Parameter page 1 using the page communication channel. Index 1 is not accessible via the ISDU communication channel. The access is redirected by the Master to the Direct Parameter page 2 using the page communication channel. Index 3 cannot be accessed by a PLC application program. The access is limited to the Master application only (Data Storage). Any ISDU request from the Master shall be responded by the Device within 5 seconds (Table 91). Any violation leads to the abortion of the actual task. Device compatibility

10.7.5

As a Device can provide compatibility to previous DeviceIDs (DID), these compatible Devices shall support all parameters and communication capabilities of the previous Devie ID. Thus, the Device is permitted to change any communication or identification parameter in this case.

61131-9/WD V0.5 IEC 2741 2742 2743 10.7.6 Protocol constants

153

Working Draft

Table 91 provides an overview of the major protocol constants for Devices. Table 91 Overview of the protocol constants for Devices
System variable ISDU acknowledgement time, for example after a SystemCommand Maximum number of entries in Index List Preset values for unused or reserved parameters, for example FunctionID Wake-up procedure MaxRetry MinCycleTime Usable Index range References B.2.2 Values 5 000 ms Definition Time from reception of an ISDU for example SystemCommand and the beginning of the response message of the Device (Figure 59) Each entry comprises an Index and a Subindex. 70 entries results in a total of 210 octets. Engineering shall set all unused parameters to the preset values.

B.2.3

70

Annex B

0 (if numbers) 0x00 (if characters)

7.3.2.2 7.3.3.3 A.3.7 and B.1.4 B.2

Table 34 and Table 35 2 Table 38 Table A.11 and Table B.3 Table B.7

Minimum and maximum timings and number of retries Maximum number of retries after communication errors Device defines its minimum cycle time to aquire input or process output data. This version of the document reserves some areas within the total range of 65 535 Indices. An event with MODE "Event appears" shall stay at least for the duration of this time. Per Device at one point in time

Errors and warnings

10.9.2

50 ms

Pending errors or warnings

10.9.2

2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 10.8 Device description (IODD)

An IODD (IO Device Description) is a file that formally describes a Device using XML notation and a corresponding schema. This file may be zipped and supplemented by all the necessary references such as images. The schema shall not be included. The IODD is created by the Device vendor and can be used by engineering tools for PLCs and/or Masters for the purpose of identification, configuration, definition of data structures for process data exchange, parameterization, and diagnosis decoding of a particular Device. Support of different languages is possible. Details of the IODD language to describe a Device together with the corresponding schemas can be found in [3]. Tools for the checking of IODD files for correctness can be downloaded from the web sites of the organization in Annex K. It is mandatory for the Device vendor to use the tools such that the file is authorized via a stamp. The IODD file is mandatory and shall be delivered with each Device (at least accessible via the Internet). 10.9 10.9.1 Device diagnosis Concepts of these for fast the text together

This document provides only most common EventCodes in D.2. It is the purpose common diagnosis informations to enable an operator or maintenance person remedial measures without deep knowledge of the Device's technology. Thus, associated with a particular EventCode shall always contain a corrective instruction with the diagnosis information.

Working Draft 2766 2767 2768 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2779

154

61131-9/WD V0.5 IEC

Fieldbus-Master-Gateways tend to only map few EventCodes to the upper system level. Usually, vendor specific EventCodes defined via the IODD can only be decoded into readable instructions via a Port Configurator or specific vendor tool using the IODD. Condensed information of the Device's "state of health" can be retrieved from the parameter "Device Status" (B.2.16). Table 92 provides an overview of the various possibilities for Devices and shows examples of consumers for this information. If implemented, it is also possible to read the number of faults since power-on or reset via the parameter "Error Count" (B.2.15) and more information in case of profile Devices via the parameter "Detailed Device Status" (B.2.17 and [12]). If required, it is highly recommended to provide additional "deep" technology specific diagnosis information in form of Device specific parameters (Table B.7) that can be retrieved via port and Device configuration tools for Masters or via vendor specific tools. Usually, only experts or service personnel of the vendor are able to draw conclusions of this information. Table 92 Classification of Device diagnosis incidents
Diagnosis incident Error (fast remedy; standard EventCodes) Error (IODD: vendor specific EventCodes; see Table D.1) Error (via Device specific parameters) Warning (fast remedy; standard EventCodes) Warning (IODD: vendor specific EventCodes; see Table D.1 ) Warning (via Device specific parameters) Notification (Standard EventCodes) Detailed Device status Appear/ disappear yes yes Single shot Parameter Destination PLC or HMI (fieldbus mapping) Port Configurator or vendor tool Port Configurator or vendor tool PLC or HMI Port Configurator or vendor tool Table B.7 Port Configurator Port Configurator or vendor tool B.2.15 Commissioning personnel Commissioning personnel and vendor service personnel Consumer Maintenance and repair personnel Vendor service personnel Vendor service personnel Maintenance and repair personnel Vendor service personnel

yes yes

Table B.7 -

yes -

Number of faults via parameter "Error Count" Device "health" via parameter "Device Status"

B.2.16, Table B.12

HMI, Tools such as "Asset Management"

Operator

2780 2781 2782 2783 2784 2785 2786 2787 2788 10.9.2 Events

The following rules apply: Events of TYPE "Error" shall use the MODEs "Event appears / disappears" (A.6.4) Events of TYPE "Warning" shall use the MODEs "Event appears / disappears" Events of TYPE "Notification" shall use the MODE "Event single shot" All "appeared" events are discarded by the Event Dispatcher when communication is interrupted or cancelled. After resume of communication the technology specific application shall enter pending events again.

61131-9/WD V0.5 IEC 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807

155

Working Draft

It is the responsibility of the Event Dispatcher to control the "Event appears" and "Event disappears" flow. A new event with MODE "Event appears" shall be preceded by an event with MODE "Event disappears". Each Event shall use a static and mode attribute. Vendor specific Events shall be fixed as an error, warning, or notification.

In order to prevent the diagnosis communication channel (Figure 5) from being flooded, the following rules shall be considered: Errors or warnings with the same EventCode shall not occur at a high rate. An event with MODE "Event appears" shall stay for at least 50 ms. Subsequent incidents of errors or warnings with the same root cause shall be suspended, that means one root cause leads to one error or warning. A Device shall not hold more than one pending error or warning at one point in time. Errors are prioritized against warnings. Visual indicators

10.9.3

The indication of SDCI communication on the Device is optional. The SDCI indication shall use a green indicator. The indication follows the timing and specification shown in Figure 88. The general perception should be "power is on". A short periodical interruption indicates SDCI communication. In order to avoid flickering, the indication cycle shall start with a "LED off" state and shall always be completed (Table 93).
LED off LED on LED on LED off LED on

Toff

2808 2809 2810 2811

Timing T rep T off T off /T rep

Trep

Figure 88 Device LED indicator timing Table 93 defines the timing for the LED indicator of Devices. Table 93 Timing for LED indicators
Minimum 750 75 7,5 Typical 1 000 100 10 Maximum 1 250 150 12,5 ms ms % Unit

2812 2813 2814 2815 2816 2817 2818 10.10 Device connectivity See 5.5 for the different possibilities of connecting Devices to Master ports and the corresponding cable types as well as the color coding. Devices can provide additional connections, for example analog outputs for compatibility reasons.

Working Draft 2819 2820 2821 2822 2823 2824 2825 2826 2827 2828

156

61131-9/WD V0.5 IEC

11 Master
11.1 11.1.1 Overview Generic model for the system integration of a Master

In 4.2 the domain of the SDCI technology within the automation hierarchy is already illustrated. Figure 89 shows exemplary the generic relationship between the SDCI technology and the fieldbus technology. Even though this may be the major use case in practice, this does not automatically imply that the SDCI technology depends on the integration into fieldbus systems. It can also be directly integrated into PLC systems, industrial PC, or other control systems without fieldbus communication in between.
PLC // Host PLC Host Fieldbus controller Fieldbus controller Fieldbus integration Engineering/HMI (Fieldbus): Network configuration, Master parameterization, Process data exchange Master/Device diagnosis, Identification & maintenance

Parameter server

Fieldbus interface Fieldbus interface Gateway application Gateway application Master Master SDCI Port 1 Port 2 Port n Data storage

Port and Device Configuration Tool (IODD): Port configuration, Device parameterization, Device diagnosis, Identification & maintenance

Device Device Application Application

Device Device Application Application

Device Device Application Application

2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844

Device description

Figure 89 Generic relationship of SDCI technology and fieldbus technology 11.1.2 Structure and services of a Master

Figure 90 provides an overview of the complete structure and the services of a Master. The Master applications comprise first a fieldbus specific gateway or direct connection to a PLC (host) for the purpose of start-up configuration and parameterization as well as process data exchange, user-program-controlled parameter change at runtime, and diagnosis propagation. For the purpose of configuration, parameterization, and diagnosis during commissioning a so-called "Configurator-Tool" (Software) is connected either directly to the Master or via fieldbus communication. These two instruments are using the following common Master applications Configuration Manager (CM), which transforms the user configuration assignments into port set-ups; On-request Data Exchange, which provides for example acyclic parameter access Data Storage (DS) mechanism, which can be used to save and restore the Device parameters;

61131-9/WD V0.5 IEC 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854

157

Working Draft

Diagnosis Unit (DU), which is processing events from the Device and propagates this diagnosis information together with Master diagnosis information to upper level automation instruments; Process Data Exchange (PDE), building the bridge to upper level automation instruments.

These Master applications provide standard methods/functions common to all Masters. The Configuration Manager (CM) and the Data Storage mechanism (DS) need special coordination in respect to On-request Data, see Figure 91 and Figure 101. The gateway application maps these functions into the features of a particular fieldbus/PLC or directly into a host system. It is not within the responsibility of this specification to define any of these gateway applications. See Annex K for the availability of specifications.
Master applications Gateway application (configuration, parameterization, diagnosis, on-request, and process data) Configuration Manager Data Storage On-request Data Exchange Diagnosis Unit
AL_GetInput

Process Data Exchange

AL_NewInput AL_SetOutput AL_PDCycle

AL_Control

AL_Read

SM_GetPortConfig

SM_SetPortConfig

SM_Operate

SM_PortMode

AL_Write

On-request data AL objects Application Layer

DL_Control DL_EventConf

AL_Abort

AL_Event

SIO: DI / DO

Process data objects

DL_PDInputTransport PD.cnf PDTrig DL_PDCycle DL_PDOutputUpdate

DL_ISDUTransport

DL_ReadParam

DL_WriteParam

DL_ISDUAbort

Port x Handler

AL_Read

Coordination

DL_Read DL_Write DL_SetMode

On-request data handler

EventFlag.ind

DL_Event

Process data handler DL-B

CMD.req

CMD.cnf

ComTrig

Data Link Layer

PDValid

PD.req

DL-A

System management
PL_Mode.req Mode switch Inactive

DL_Mode

Master DL-mode handler

FHInfo CMD.req CMD.cnf

Frame handler
PL_Transfer.req PL_Transfer.ind SIO: DI / DO

PL_WakeUp.req

Wake-up

Coded switching

Switching signal

2855 2856 2857

Physical layer (port)

Figure 90 Structure and services of a Master Figure 91 shows the relationship of the common Master applications.

Working Draft

158

61131-9/WD V0.5 IEC

Gateway application (configuration, parameterization, diagnosis, on-request, and process data) Gateway application (configuration, parameterization, diagnosis, on-request, and process data)
Start of port and Device OperatingMode Data Storage interface On-request Data interface Diagnosis interface Process Data interface

DS_Delete

Operating or Fault

OD_Start

OD_Stop

DU_Start

DU_Stop

Events

PD_Start

PD_Stop

Data

Data

DS_Startup

OD_Block

Configuration Configuration Managment Managment (CM) (CM)

DS_Ready DS_Fault

Data Data Storage Storage (DS) (DS)

OD_Unblock

On-request On-request Data Data Exchange Exchange (ODE) (ODE)

DS_ UPLOAD _REQ

Diagnosis Diagnosis Unit Unit (DU) (DU)

Process Process Data Data Exchange Exchange (PDE) (PDE)

AL_Write

AL_Read

AL_Write

AL_Read

AL_Event AL_Event (response) (Indication) AL_Control AL_PD-Services

2858 2859 2860 2861 2862 2863

SM-Services

Figure 91 Relationship of the common Master applications The internal variables between the common Master applications are defined in Table 94. The main responsibility is assigned to the Configuration Manager (CM) as shown in Figure 91 and explained in 11.2. Table 94 Internal variables and events to control the common Master applications
Internal Variable DS_Startup DS_Ready DS_Fault DS_Delete DS_UPLOAD_REQ OD_Start OD_Stop OD_Block OD_Unblock DU_Start DU_Stop Definition This variable triggers the Data Storage (DS) state machine causing an Upload or Download of Device parameters if required (11.3). This variable indicates the Data Storage has been accomplished successfully; operating mode is CFGCOM or AUTOCOM (9.2.2.2) This variable indicates the Data Storage has been aborted due to a fault. Any verified change of Device configuration leads to a deletion of the stored data set in the Data Storage. This special event "DS_UPLOAD_REQ" from the Device triggers the Data Storage state machine in the Master. This variable enables On-request Data access via AL_Read and AL_Write. This variable indicates that On-request Data access via AL_Read and AL_Write is acknowledged with a negative response to the gateway application. Data Storage upload and download actions disable the On-request Data access through AL_Read or AL_Write. Access by the gateway application is denied. This variable enables On-request Data access via AL_Read or AL_Write. This variable enables the Diagnosis Unit to propagate remote (Device) or local (Master) events to the gateway application. This variable indicates that the Device events are not propagated to the gateway application and not acknowledged. Available Events are blocked until the DU is enabled again. This variable enables the Process Data exchange with the gateway application. This variable disables the Process Data exchange with the gateway application.

PD_Start PD_Stop

2864

Data

61131-9/WD V0.5 IEC 2865 2866 2867 2868 2869 2870 2871 2872 2873 2874 2875 2876 2877 11.2 11.2.1 Configuration Manager (CM) General

159

Working Draft

Figure 91 and Figure 92 illustrate the coordinating role of the Configuration Manager amongst all the common Master applications. After setting up a port to the assigned modes ( 11.2.2.1 through 11.2.2.3), CM starts the Data Storage mechanism (DS) and returns the variable "Operating" or "Fault" to the gateway application. In case of the variable "Operating" of a particular port, the gateway application activates the state machines of the associated Diagnosis Unit (DU), the On-request Data Exchange (ODE), and the Process Data Exchange (PDE). After all SDCI ports are ready ("ReadytoOperate", see Figure 92), the gateway application shall activate all ports ("StartOperate") to ensure that synchronization of port cycles can take place. Finally, the Devices are exchanging Process Data ("Operating"). In case of error the gateway application receives "Communication stopped".
Gateway CM SM DS ODE DU PDE

OperatingMode(SDCI) SM_SetPortConfig(CFGCOM) SM_PortMode(CFGCOM) DS_Startup() OD_Block() Data Storage active: Download, upload, none OD_Unblock() DS_Ready() ReadyToOperate() StartOperate() SM_Operate() SM_PortMode(OPERATE) Operating() OD_Start() PD_Start() DU_Start() Process Data Exchange enabled Activates all ports On-request Data Exchange enabled Gateway access to On-request Data disabled

All ports are working in cyclic Process Data exchange. Device available for example to a fieldbus system

Processing of events enabled. Event "DS_UPLOAD_REQ" occurs DS_UploadRequest() OD_Block() Gateway access to On-request Data disabled OD_Unblock()

2878 2879 Figure 92 Sequence diagram of Configuration Manager actions

Working Draft 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918

160

61131-9/WD V0.5 IEC

In case of a fault (e.g. RevisionFault, see Figure 66), only the ODE machine will be activated to allow for parameterization. At each new start of a port the gateway application will first de-activate (e.g. OD_Stop) the associated machines DU, ODE, and PDE. Several parameters are available for the Configuration Manager to achieve a specific behaviour. 11.2.2 11.2.2.1 Configuration parameter OperatingMode

One of the following operating modes can be selected. All modes are mandatory. Inactive The SDCI port is deactivated, the corresponding process data length for input and output is zero. The Master shall not have any activities on this port. DO The SDCI port is configurated as a digital output (see Table 2 for constraints). The output process data length is 1 bit. The Master shall not try to wake up any Device at this port. DI The SDCI port is configurated as a digital input. The input process data length is 1 bit. The Master shall not try to wake up any Device at this port. SDCI An SDCI port is configured for continuous communication. The defined identification is checked. Whether a difference in Device identification will lead to the rejection of the Device or not depends on the port configuration (InspectionLevel, see Table 71). ScanMode The SDCI port is configured for continuous communication. The identification is read back from the Device and provided as the new defined identification. Otherwise see OperatingMode "SDCI". 11.2.2.2 PortCycle

One of the following port cycle modes can be selected. None of the modes is mandatory. FreeRunning The port cycle timing is not restricted. FixedValue The port cycle timing is fixed to a specific value. If the Device is not able to achieve this timing, for example the timing is lower than the MinCycleTime of the Device, an error shall be generated. The fixed value can be written in the CycleTime parameter as defined in 11.2.2.3. MessageSync The port cycle timing is restricted to the synchronous start of all messages (frames) on all SDCI ports of this Master. In this case the cycle time is given by the highest MinCycleTime of the connected Devices. All Master ports set to this mode are working with this behaviour as shown in Figure 93. Values for displacement and jitter shall be noted in the user manual.

61131-9/WD V0.5 IEC

Port 1 Port 2 Port 3 Port 4 CycleTime

161

Working Draft

2919 2920 2921 2922 2923 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2934 2935 2936 2937 2938 2939 2940 2941 2942 2943 2944 2945 2946 2947 2948 2949 2950 11.2.2.3 CycleTime

Figure 93 Ports in MessageSync mode

This parameter contains the requested or actual cycle time for the specific ports. It shall be passed as a value with a resolution of 100 s. 11.2.2.4 PDConfig

This set of parameters contains the rules for the process data mapping between the Device Process Data stream and the gateway Process Data stream. LenIn This parameter contains the requested length of the Device input ProcessDataIn Bits. PosIn This parameter contains the offset within the gateway input Process Data stream in Bit. SrcOffsetIn This parameter contains the offset within the Device input Process Data stream in Bit. LenOut This parameter contains the requested length of the Device output ProcessDataOut Bits. PosOut This parameter contains the offset within the gateway output Process Data stream in Bit. SrcOffsetOut This parameter contains the offset within the Device output Process Data stream in Bit. 11.2.2.5 DeviceIdentification

This set of parameters contains the actual configured Device identification. VendorID This parameter contains the requested or read vendor specific ID as described in B.1.9. DeviceID This parameter contains the requested or read Device specific ID as described in B.1.10. SerialNumber This parameter contains the requested or read SerialNumber as described in B.2.11. InspectionLevel This parameter contains the requested InspectionLevel as described in Table 71. 11.2.2.6 DataStorageConfig

This set of parameter items contains the settings of the Data Storage mechanism.

Working Draft 2951 2952 2953 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2971 2972 2973 2974

162

61131-9/WD V0.5 IEC

ActivationState This parameter contains the requested state of the Data Storage mechanism for this port. The following modes are supported: Enabled The Data Storage mechanism is active and provides the full functionality as described in 11.3.2. Disabled The Data Storage mechanism is inactive and the complete parameter set of this port remains stored. Cleared The Data Storage mechanism is disabled and the stored parameter set of this port is cleared. DownloadEnable If this configuration is enabled, the Data Storage mechanism is permitted to write data to the connected Device. UploadEnable If this configuration is enabled, the Data Storage mechanism is permitted to read data from the connected Device. 11.2.3 State machine of the Configuration Manager

Figure 94 shows the state machine of the Master configuration manager. The different states show the steps of necessary commands to establish or maintain communication or the DI or DO state. Any change of the port configuration can be activated by changing the OperatingMode variable (11.2.2.1).

61131-9/WD V0.5 IEC

163

Working Draft

/Initialization [Inactive]/T13 [DO]/T12

SM_PortMode_yMODE/T10

Inactive_0

Port_DIDO_7

[DI]/T11 [AUTOCOM]/ T2 [SDCI]/ T1 SM_Startup_1

PortFault_3

SM_PortMode_xFAULT/ T4 SM_PortMode_CFGCOM/ T3 SM_PortMode_AUTOCOM/ T5

[DS_Fault]/T7

DS_ParamManager_2

[DS_Ready]/ T6 CM_ReadyToOperate_4

[StartOperate]/ T8 WaitingOnOperate_5

SM_PortMode_OPERATE/ T9 Port_Active_6

2975 2976 2977 2978

Key xFAULT: REV_FAULT or COMP_FAULT or SERNUM_FAULT yMODE: INACTIVE or COMLOSS

Figure 94 State machine of the Configuration Manager Table 95 shows the state transition table of the Configuration Manager state machine. Table 95 State transition tables of the Configuration Manager
STATE NAME Inactive_0 SM_Startup_1 DS_ParamManager_2 PortFault_3 CM_ReadytoOperate_4 WaitingOnOperate_5 PortActive_6 PortDIDO_7 STATE DESCRIPTION Waiting on any of the OperatingMode variables from the gateway application: DO, DI, SDCI, and ScanMode. Waiting on an established communication or loss of communication or any of the faults REV_FAULT, COMP_FAULT, or SERNUM_FAULT (Figure 66). Waiting on accomplished Data Storage startup. Parameter are downloaded into the Device or uploaded from the Device. Device in state PREOPERATE (communicating). However, one of the three faults REV_FAULT, COMP_FAULT, SERNUM_FAULT, or DS_Fault occurred. Port is waiting until the gateway application indicates "StartOperate". Waiting on SM to switch to OPERATE. Port is in OPERATE mode. The gateway application is exchanging Process Data and ready to send or receive On-request Data. Port is in DI or DO mode. The gateway application is exchanging Process Data (DI or DO).

Working Draft 2979

TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 SOURCE STATE 0 0 1 1 1 2 2 4 5 1,2,3,4,5, 6 0 0 7 TARGET STATE 1 1 2 3 2 4 3 5 6 0 7 7 0 TYPE Bool Bool Bool Bool Bool Bool Bool

164
ACTION SM_SetPortConfig_CFGCOM SM_SetPortConfig_AUTOCOM

61131-9/WD V0.5 IEC

DS_Startup: The DS state machine is triggered. ConfigFault indication to gateway application (REV_FAULT, COMP_FAULT, or SERNUM_FAULT). DS_Startup: The DS state machine is triggered. Indication to gateway application: ReadyToOperate Data Storage failed. Rollback to previous parameter set. SM_Operate. Indication to gateway application: "Operating" (see Figure 92). SM_SetPortConfig_INACTIVE. Indication to gateway application: COMLOSS or INACTIVE SM_SetPortConfig_DI. Indication to gateway application: DI SM_SetPortConfig_DO. Indication to gateway application: DO SM_SetPortConfig_INACTIVE. DEFINITION Data Storage sequence (upload, download) accomplished. Port operating mode is SDCI or ScanMode. See Table 94. See Table 94. Gateway application causes the port to switch to OPERATE. One of the OperatingModes (11.2.2.1) One of the OperatingModes (11.2.2.1) One of the OperatingModes (11.2.2.1) One of the OperatingModes (11.2.2.1)

2980

T13

INTERNAL ITEMS DS_Ready DS_Fault StartOperate SDCI AUTOCOM DI DO

2981 2982 2983 2984 2985 2986 2987 2988 2989 2990 2991 2992 2993 2994 2995 2996 2997 2998 11.3 11.3.1 Data Storage (DS) Overview

Data Storage between Master and Device is specified within this document, whereas the adjacent upper Data Storage mechanisms depend on the individual fieldbus or system. The Device holds a standardized set of objects providing parameters for data storage, memory size requirements, control and state information of the Data Storage mechanism. Changes of Data Storage parameter sets are detectable via the "Parameter Checksum" (10.4.8). 11.3.2 DS data object

The structure of a Data Storage data object is described in Annex F in Table F.1. The Master shall always hold the header information (Parameter Checksum, VendorID, and DeviceID) for the purpose of checking and control. The object information (objects 1n) will be stored within the non-volatile memory part of the Master (Annex F). Prior to a download of the Data Storage data object (parameter block), the Master will check the consistency of the header information with the particular Device. The maximum permitted size of the Data Storage data object is 2 * 2 10 octets. It is mandatory for Masters to provide at least this memory space per port if the Data Storage mechanism is implemented.

61131-9/WD V0.5 IEC 2999 3000 3001 3002 3003 11.3.3 DS state machine

165

Working Draft

The Data Storage mechanism is called right after establishing the SDCI communication, before entering the OPERATE mode. During this time any other communication with the Device shall be rejected by the gateway. Figure 95 shows the state machine of the Data Storage mechanism.

/Initialization CheckActivationState_0 [DS_Off or DS_Deactivated]/T7 DS_Upload_Req/ T13 DS_Startup/ T14

[DS_Activated & COM]/ T6 [DS_Activated & NoCOM]/ T8

Off_3

DS_Delete/ T10

[DS_Activated]/T1 DS_Off/ T11 UpDownload_2 DS_Upload_Req/T4 WaitingOnDSActivity_1

[DS_Ready]/T3 enex_1 enex_2 DS_Fault/T5 [DS_Delete]/T9 DS_Startup/T2 DS_Deactivated/ T12

3004 3005 3006 3007 3008

Figure 95 Main state machine of the Data Storage mechanism Figure 96 shows the submachine of the state "UpDownload_2". This submachine can be invoked by the Data Storage mechanism or during runtime triggered by a "DS_UPLOAD_REQ" event.

Working Draft

166
UpDownload_2

61131-9/WD V0.5 IEC

[Identification_Fault]/T15

CheckIdentity_4

[Identification_Passed]/ T16 [SizeCheck_Fault]/T17 CheckSize_5

[SizeCheck_Passed]/ T18 [DS_UPLOAD_Flag & Upload_Enable]/ T19

CheckUpload_6

[NoUpload_Requested]/ T20

CheckDSValidity_8 [Upload_Fault]/T23 [DS_Valid]/ T22 CheckChecksum_9

[DS_Invalid & Upload_Enable]/ T21

Upload_7 enex_3 enex_4 [Upload_Done]/ T26 DS_Ready_11 [Checksum_Match]/ T25

[Checksum_Mismatch & Download_Enable]/ T24 DS_Fault_12 Download_10

enex_5 [Download_Fault]/T28

enex_6 [Download_Done]/T27 enex_2 [DS_Ready]

enex_1 [DS_Fault]

3009 3010 3011 3012 3013 Figure 96 Submachine "UpDownload_2" of the Data Storage mechanism Figure 97 shows the submachine of the state "Upload_7". This state machine can be invoked by the Data Storage mechanism or during runtime triggered by a DS_UPLOAD_REQ event.

61131-9/WD V0.5 IEC

167
Upload_7

Working Draft

ReadParameter_14

[DataIncomplete]/T29

DecomposeIndexList_13

[DataRead]/T30 [Device_Error]/ T31 [COM_ERROR]/ T32 [COM_ERROR]/T33 [DataComplete]/ T34

Upload_Fault_16

[COM_ERROR]/T35

StoreDataSet_15

[Upload_Fault]

enex_3

enex_4

[Upload_Done]

3014 3015 3016 3017 3018 Figure 97 Data Storage submachine "Upload_7" Figure 98 demonstrates the Data Storage upload sequence using the Data Storage Index (DSI) defined in B.2.3 and Table B.9. The structure of Index_List is defined in Table B.10. The DS_UPLOAD_FLAG shall be reset at the end of each sequence (Table B.9).
Master Data Storage AL_Read(DSI: Index 3, Subindex 5, Index_List) Response(Index_List) Device Data Storage

232 Index 0...65535, 232 octets/index maximum

AL_Write(DSI: Index 3, Subindex 1, DS_UploadStart) Response(+)

Header Entry X1

AL_Read(DSI: Index_List, Entry X1) Response(Content of Entry X1)

...
Entry Xn Data Storage memory
AL_Read(DSI: Index_List, Entry Xn) Response(Content of Entry Xn) AL_Read(DSI: Index 3, Subindex 4) Response(Parameter Checksum)

... 0x00 15

AL_Write(DSI: Index 3, Subindex 1, DS_UploadEnd) Response(+) Reset DS_UPLOAD_FLAG

Key DSI = Data Storage Index

3019 3020 3021 3022 3023 Figure 99 shows the submachine of the state "Download_10". This state machine can be invoked by the Data Storage mechanism. Figure 98 Data Storage upload sequence diagram

Working Draft

168
Download_10

61131-9/WD V0.5 IEC

WriteParameter_18

[Remaining_Data]/T36 [Write_done]/T37

DecomposeSet_17

[Device_Error]/ T38

[COM_ERROR]/ T39

[Data_completed]/ T40

Download_Fault_20 [COM_ERROR]/ T41

DownloadDone_19

[Download_Fault]

enex_5

enex_6

[Download_Done]

3024 3025 3026 3027 3028 Figure 99 Data Storage submachine "Download_10" Figure 100 demonstrates the Data Storage download sequence using the Data Storage Index (DSI) defined in B.2.3 and Table B.9. The structure of Index_List is defined in Table B.10. The DS_UPLOAD_FLAG shall be reset at the end of each sequence (Table B.9).
Master Data Storage AL_Write(DSI: Index 3, Subindex 1, DS_DownloadStart) Response(+) Device Data Storage

232 Index 0...65535, 232 octets/index maximum

Header Entry X1

AL_Write(DSI: Index_List, Entry X1) Response(+)

...
Entry Xn
AL_Write(DSI: Index_List, Entry Xn)

Data Storage memory

Response(+)

AL_Read(DSI: Index 3, Subindex 4) Response(Parameter Checksum)

... 0x00 15

AL_Write(DSI: Index 3, Subindex 1, DS_DownloadEnd) Response(+) Reset DS_UPLOAD_FLAG

Key DSI = Data Storage Index

3029 3030 3031 3032 Figure 100 Data Storage download sequence diagram Table 96 shows the states and transitions of the Data Storage state machines. Table 96 States and transitions of the Data Storage state machines
STATE NAME CheckActivationState_0 STATE DESCRIPTION Check current state of the DS configuration: Independently from communication status, DS_Startup from Configuration Management or an event DS_UPLOAD_REQ is

61131-9/WD V0.5 IEC

STATE NAME expected. WaitingOnDSActivity_1 UpDownload_2 Off_3 SM: CheckIdentity_4 SM: CheckSize_5 SM: CheckUpload_6 SM: Upload_7 SM: CheckDSValidity_8 SM: CheckChecksum_9 SM: Download_10 SM: DS_Ready_11 SM: DS_Fault_12 SM: Decompose_IL_13 SM: ReadParameter_14 SM: StoreDataSet_15 SM: Upload_Fault_16 SM: Decompose_Set_17 SM: Write_Parameter_18 SM: Download_Done_19 SM: Download_Fault_20

169
STATE DESCRIPTION

Working Draft

Waiting for upload request, Device startup, all changes of activation state independent of the Device communication state. Submachine for up/download actions and checks Data Storage handling switched off or deactivated Check Device identification against data set content (Table F.2). No content does not lead to a fault. Check data set size (Index 3, Subindex 3) against available Master storage size Check for DS_UPLOAD_FLAG within the Data Storage Index (Table B.9) Submachine for the upload actions Check whether stored data set is valid or invalid Check for differences between the data set content and the Device parameter via the "Parameter Checksum" within the Data Storage Index (Table B.9) Submachine for the download actions Prepare DS_Ready indication to the Configuration Management (CM) Prepare DS_Fault indication from "Identification_Fault", "SizeCheck_Fault", "Upload_Fault", and "Download_Fault" to the Configuration Management (CM) Read Index List within the Data Storage Index (Table B.9). Read content entry by entry of the Index List from the Device (Table B.10). Wait until read content of one entry of the Index List from the Device is accomplished. Task of the gateway application: store entire data set according to Table F.1 and Table F.2 Prepare Upload_Fault indication from "Device_Error" and "COM_ERROR" as input for the higher level indication DS_Fault. Write parameter by parameter of the data set into the Device according to Table F.1. Wait until write of one parameter of the data set into the Device is accomplished. Download completed. Read back "Parameter Checksum" from the Data Storage Index according Table B.9. Save this value in the stored data set according to Table F.2. Prepare Download_Fault indication from "Device_Error" and "COM_ERROR" as input for the higher level indication DS_Fault. TARGET STATE 1 2 1 2 1 OD_Unblock; Indicate DS_Ready to CM Confirm event "DS_UploadRequest" DS_Break (AL_Write, Index 3, Subindex 1); clear intermediate data (garbage collection); rollback to previous parameter state; DS_Fault (see Figure 91); OD_Unblock. Clear saved parameter set (Table F.1 and Table F.2) Clear saved parameter set (Table F.1 and Table F.2) Clear saved parameter set (Table F.1 and Table F.2) Confirm event "DS_UploadRequest"; no further action DS_Ready to CM ACTION

3033
TRANSITION T1 T2 T3 T4 T5 SOURCE STATE 0 1 2 1 2

T6 T7 T8 T9 T10 T11 T12 T13 T14

3 0 3 1 3 1 1 3 3

2 3 1 1 3 3 3 3 3

Working Draft
TRANSITION T15 T16 T17 T18 T19 T20 T21 T22 T23 T24 T25 T26 T27 T28 T29 T30 T31 T32 T33 T34 T35 T36 T37 T38 T39 T40 SOURCE STATE 4 4 5 5 6 6 8 8 7 9 9 7 10 10 13 14 14 14 13 13 15 17 18 18 18 17 19 TARGET STATE 12 5 12 6 7 8 7 9 12 10 11 11 11 12 14 13 16 16 16 15 16 18 17 20 20 19 20 TYPE Bool Bool Bool Bool Bool Variable Bool Bool Event Bool Bool Bool Bool

170
ACTION

61131-9/WD V0.5 IEC

Indicate DS_Fault(Identification_Fault) to the gateway application Read "Data Storage Size" according to Table B.9, OD_Block Indicate DS_Fault(SizeCheck_Fault) to the gateway application Read "DS_UPLOAD_FLAG" according to Table B.9 Data Storage Index 3, Subindex 1: "DS_UploadStart" (Table B.9) Data Storage Index 3, Subindex 1: "DS_UploadStart" ( Table B.9) Data Storage Index 3, Subindex 1: "DS_Break" (Table B.9). Indicate "DS_Fault(Upload)" to the gateway application Data Storage Index 3, Subindex 1: "DS_DownloadStart" (Table B.9) Data Storage Index 3, Subindex 1: "DS_UploadEnd"; read Parameter Checksum (Table B.9) Data Storage Index 3, Subindex 1: "DS_DownloadEnd" (Table B.9) Data Storage Index 3, Subindex 1: "DS_Break" (Table B.9). Indicate "DS_Fault(Download)" to the gateway application. AL_Read (Index List) Read "Parameter Checksum" (Table B.9). Write parameter via AL_Write Read "Parameter Checksum" (Table B.9). DEFINITION Data Storage handling switched off, see 11.2.2.6 Data Storage handling deactivated, see 11.2.2.6 Data Storage handling activated, see 11.2.2.6 Error in communication detected Access to Index denied, AL_Read or AL_Write.cnf(-) with ErrorCode 0x80 Trigger from CM state machine, see Figure 91 No communication Communication OK See Table D.2 Data Storage handling configuration, see 11.2.2.6 Data Storage handling configuration, see 11.2.2.6 Still data transmission to perform, parameter list not completed All parameter octets transmitted

3034

T41

INTERNAL ITEMS DS_Off DS_Deactivated DS_Activated COM_ERROR Device_Error DS_Startup NoCOM COM DS_UPLOAD_REQ UploadEnable DownloadEnable DataIncomplete DataComplete

61131-9/WD V0.5 IEC

INTERNAL ITEMS SizeCheckPassed IdentificationPassed NoUploadRequested DS_Valid DS_Invalid Checksum_Mismatch Checksum_Match Download_Done Upload_Done TYPE Bool Bool Bool Bool Bool Bool Bool Bool Bool

171
DEFINITION

Working Draft

Required memory space for parameter smaller than available Data Storage space within the Master The identification data of the connected Device (DeviceID, VendorID) match the parameter set within the Data Storage. DS_UPLOAD_FLAG not set, see Table B.9 Valid parameter set available within the Master No valid parameter set available within the Master Acquired "Parameter Checksum" from Device does not match the checksum within Data Storage (binary comparison) Acquired "Parameter Checksum" from Devive matches the checksum within Data Storage (binary comparison) Download of parameters accomplished successfully Upload of parameters accomplished successfully

3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 11.4 On-Request Data exchange (ODE) 11.3.4 Parameter selection for Data Storage

The Device vendor defines the parameters that are part of the Data Storage mechanism. The IODD marks these parameters with the attribute "Remanent.DataStorage". However, the Data Storage mechanism shall not consider the information from the IODD but rather the Parameter List read out from the Device.

Figure 101 shows the state machine of the Master's On-request Data Exchange. This behaviour is mandatory for a Master. During an active data transmission of the Data Storage mechanism, all On-request Data requests are blocked.
[ODrequest]/T1

Inactive_0

OD_Start/ T2

OD_Stop/ T3 [ODrequest]/T4 OD_Block/T5 [ODrequest]/T6

ODactive_1

ODblocked_2

OD_Unblock/T7

3047 3048 3049 3050

STATE NAME

Figure 101 State machine of the On-request Data Exchange Table 97 shows the state transition table of the On-request Data Exchange state machine. Table 97 State transition table of the ODE state machine
STATE DESCRIPTION

Working Draft
STATE NAME Inactive_0 ODactive_1 Waiting for activation

172
STATE DESCRIPTION

61131-9/WD V0.5 IEC

On-request communication active using AL_Read or AL_Write On-request communication blocked SOURCE STATE 0 0 1 1 1 2 2 TARGET STATE 0 1 0 1 2 2 1 TYPE Variable Variable On-request Data On-request Data read or write requested ACTION Access blocked (inactive): indicates "Service not available" to the gateway application AL_Read or AL_Write Access blocked temporarily: indicates "Service not available" to the gateway application DEFINITION

3051

ODblocked_2 TRANSITION T1 T2 T3 T4 T5 T6 T7

3052
OD

INTERNAL ITEMS

ODrequest

3053 3054 3055 3056 3057 3058 3059 3060 3061 3062 3063 3064 3065 3066 3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 11.5 11.5.1 Diagnosis Unit (DU) Generic diagnosis model

Main goal for diagnosis information is to reach an operator in an efficient manner. That means: No diagnosis information flooding Report of the root cause of an incident within a Device or within the Master and not subsequent correlated faults Diagnosis information shall provide information on how to maintain or repair the affected component for fast recovery of the automation system.

Figure 102 demonstrates exemplary the diagnosis information flow through a complete SDCI/fieldbus system.
NOTE The flow can end at the Master/PDCT or be more integrated depending on the fieldbus capabilities.

Within SDCI, diagnosis information of Devices is conveyed to the Master via Events consisting of EventQualifiers and EventCodes (A.6). The associated human readable text is available for standardized EventCodes within this document (Annex D) and for vendor specific EventCodes within the associated IODD file of a Device. The standardized EventCodes can be mapped to semantically identical or closest fieldbus channel diagnosis definitions within the gateway application. Vendor specific IODD codings can be mapped to manufacturer specific channel diagnosis definitions (individual code and associated human readable information) within the fieldbus device description file. Fieldbus engineering tools and process monitoring systems (human machine interfaces) can use the fieldbus device description to decode the received fieldbus diagnosis code into human readable diagnosis text.

61131-9/WD V0.5 IEC

173
Process monitoring (Human Machine Interface - HMI): Fieldbus device diagnosis SDCI Master/Device diagnosis

Working Draft

Factory backbone
Engineering (Fieldbus): SDCI Master/Device diagnosis

PLC // Host PLC Host Fieldbus controller Fieldbus controller Fieldbus

Field device description file

Field device description file Port and Device configuration tool (IODD): Display SDCI Device diagnosis

Fieldbus interface Fieldbus interface Gateway application Gateway application Master Master Port 1 Port n

Standard channel Standard channel diagnosis diagnosis

Specific channel Specific channel diagnosis diagnosis

Mapping Mapping
Standard Standard events events Specific Specific events events

Device Device Application Application

Device description IODD

Device Device Application Application

Device description IODD

IODD defined Events IODD file

3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3089 3090 3091 3092 3093 3094

Figure 102 System overview of SDCI diagnosis information propagation via Events

11.5.2

DU responsibility and Event scheduling

The Diagnosis Unit receives events from the Device applications (Step 1 in Figure 103). They are propagated to the gateway application (Step 2). Diagnosis information flooding is avoided through flow control, which allows only one Event per Device to be propagated to the Master/gateway application at a time. The next Event (Step 5) can be casted only after an acknowledgement of the Master/gateway application (Step 3) and received by the Device application. The time for the acknowledgement is depending on the fieldbus system or the gateway application respectively. It is highly recommended to pay attention to very short acknowledgement times as a Device cannot cast another Event if the previous Event is still pending. See Table 91 for system constants to be considered for the design. The special DS_UPLOAD_REQ event (see 10.4 and Table D.2) of a Device shall be redirected to the common Master application Data Storage. Those events are acknowledged by the DU itself and not propagated to the gateway. The gateway application is able to start or stop the Diagnosis Unit (Figure 91). When stopped, the DU is defering any received AL_Event.ind call until the DU is started again.

Working Draft
Master Diagnosis Unit Master AL

174
Master DL Portx Device DL

61131-9/WD V0.5 IEC

Device AL Device App

DL_Event_ind() DL_EventTrigger_req() Step 2: Event propagated to the gateway application Message() DL_Event_ind() AL_Event_ind() AL_Event_rsp()

AL_Event_req()

Step 1: Event x occurs

Step 3: Event acknowledged by the gateway application

DL_EventConf_req() Message() DL_EventTrigger_cnf() AL_Event_cnf() Step 4: Event acknowledged to Device application AL_Event_req() DL_Event_req() DL_EventTrigger_req() Step 5: Event x+1 occurs

3095 3096 3097 3098 3099 3100 3101 3102 3103 3104 3105 3106 3107 3108 3109 3110 3111 3112 3113 3114 3115 11.5.3 Figure 103 Event scheduling Multi Event transport

Besides the method described in 11.5.2 in which each single event is conveyed through the layers and acknowledged by the gateway application, SDCI supports a so-called "multi event transport" for compatibility reasons to previous protocol versions (Table A.16). This means, 1 up to 6 Events can be conveyed at a time. The DU serializes the Event set into single diagnosis indications to the gateway application and returns one acknowledgement for the entire set to the Device application.
NOTE One AL_Event.req carries up to 6 Event elements and one AL_Event.ind indicates up to 6 pending Event elements. AL_Event.rsp and AL_Event.cnf refer to the indicated entire Event set.

Figure 104 demonstrates the mechanism of a "multi event transport". It defines the behaviour of the DU in the following steps: Up to 6 elements of the Event set (AL_Event.ind) are entered into a serializer queue within the DU in ascending order. The first element of the set is indicated to the gateway application as a "diagnosis report". After the acknowledgement of this first element by the gateway application, it will be removed from the queue and the next element will be indicated to the gateway application. After processing all elements within the queue in the same manner, the DU will acknowledge the entire set to the DL and finally to the Device application.

61131-9/WD V0.5 IEC

Master Diagnosis Unit Master AL

175
Master DL Portx Device DL Device AL

Working Draft
Device App

AL_Event_req() DL_Event_req(first) DL_Event_req(second) DL_Event_req(third) DL_EventTrigger_req() Message() DU serializes the Event set into single diagnosis reports to the gateway application and waits on each acknowledgement DL_Event_ind(first) DL_Event_ind(second) DL_Event_ind(third) AL_Event_ind() (Event set of 3) AL_Event_rsp() DL_EventConf_req() Message() DL_EventTrigger_cnf() AL_Event_cnf() (entire Event set)

3116 3117 3118 3119 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 11.6 11.6.1 PD Exchange (PDE) General Figure 104 Event scheduling (multi event transport)

The Process Data Exchange provides the transmission of Process Data between the gateway application and the connected Device. After an established communication and Data Storage, the port is ready for any On-request Data (ODE) transfers. The Process Data communication is enabled whenever the specific port or all ports are switched to the OPERATE mode. 11.6.2 Process Data mapping

According to 11.2.2.4 the input and output Process Data are mapped to a specific part of the gateway process data stream. Figure 105 illustrates exemplary the mapping of the Process Data from 3 Master ports to the Gateway Process Data stream.

Working Draft
Octet Bit 7 5 07 4 07 3 07 2 07 1

176
0 07 0

61131-9/WD V0.5 IEC

Gateway Process Data stream

07

0 Port 1 : LenIn 16; PosIn 0; SrcOffsetIn 0

07

0 Port 2 : LenIn 8; PosIn 16; SrcOffsetIn 4

07

0 Port 3 : LenIn 1; PosIn 24; SrcOffsetIn 11

3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 11.6.3 Process Data invalid

Figure 105 Process Data mapping from ports to the gateway data stream

The Master informs the Device about the Process Data validity status by sending MasterCommands (see Table B.2) to the Direct Parameter page. A sample transmission of PDout state from Master application to Device application is shown in the upper section of Figure 106. The Device sends the Process Data validity status in every single frame as the PD_Invalid flag in the Checksum / Status (CKS) octet (A.1.5). A sample transmission of PDin state from Device application to Master application is shown in the lower section of Figure 106. Any perturbation while in interleave transmission mode leads to a Process Data invalid indication.

61131-9/WD V0.5 IEC

Master App Master AL Master DL Portx

177
Device DL Device AL

Working Draft
Device App

AL_Control() (PD_INVALD) DL_Control() (PD_INVALD) MasterCommand() ("DeviceOperate")

DL_Control() (PD_INVALD) AL_Control() (PD_INVALD)

AL_Control() DL_Control() ChecksumStatus() DL_Control() AL_Control() (PD_INVALD) (PD_INVALD) ChecksumStatus() ("PD_Invalid flag") ("PD_Invalid flag") (PD_INVALD) (PD_INVALD)

ChecksumStatus() ("PD_Invalid flag")

...
DL_Control() ChecksumStatus() DL_Control() AL_Control() (PD_VALD) (PD_VALD) (PD_VALD)

AL_Control() (PD_VALD)

3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 11.7 11.7.1 Port and Device configuration tool (PDCT) General Figure 106 Propagation of PD_Invalid from Master to Device

Figure 89 and Figure 102 demonstrate the necessity of a tool to configure ports, parameterize the Device, display diagnosis information, and provide identification and maintenance information. Depending on the degree of integration into a fieldbus system, the PDCT functions can be reduced, for example if the port configuration can be achieved via the field device description file of the particular fieldbus. The PDCT functionality can be integrated partially (navigation, parameter transfer, etc.) or completely into the engineering tool of the particular fieldbus. 11.7.2 Basic layout examples

Figure 107 shows one example of a PDCT display layout.

Working Draft
Topology Toplevel Toplevel -- Master Master -- Port 1: Device A Port 1: Device A -- Port 2: Device B Port 2: Device B -- -- Port n: Device Z Port n: Device Z Identification Monitoring

178
Parameter Diagnosis Process Data

61131-9/WD V0.5 IEC

Device Catalog Vendor Vendor Vendor 1 Vendor 1 Vendor 2 Vendor 2 Vendor n Vendor n Device Device Device a Device a Device b Device b Device c Device c Device z Device z

Layout of this window Layout of this window defined by the IODD of defined by the IODD of the connected Device the connected Device

3158 3159 3160 3161 3162 3163 Figure 107 Example 1 of a PDCT display layout The PDCT display should always provide a navigation window for a project or a network topology, a window for the particular view on a chosen Device that is defined by its IODD, and a window for the available Devices based on the installed IODD files. Figure 108 shows another example of a PDCT display layout.
Project Tree Toplevel Toplevel -- Master Master -- Port 1: Port 1: -- Device A Device A -- Port 2: Port 2: -- Device B Device B -- -- Port n: Port n: -- Device Z Device Z
Menu Identification Monitoring Parameter Diagnosis Process Data Parameter

Device Library Vendor 1 Vendor 1 -- Device a V1.03 Device a V1.03 -- Device b V1.23 Device b V1.23 -- Device c V2.00 Device c V2.00 -- Vendor 2 Vendor 2 -- Device aa V0.99 Device aa V0.99 -- Device bb V1.1.2 Device bb V1.1.2 -- Vendor n Vendor n -- Device xxx V2.3.04 Device xxx V2.3.04 -- Device yyy V1.3 Device yyy V1.3 -- Device zzz V123 Device zzz V123

Layout of this window defined by the IODD of the connected Device

3164 3165 3166 3167 3168 3169 3170 3171 3172 Figure 108 Example 2 of a PDCT display layout Further information can be retrieved from [2]. 11.8 11.8.1 Gateway application General

The Gateway application depends on the individual host system (fieldbus, PLC, etc.) the Master applications are embedded in. It is the responsibility of the individual system to specify the mapping of the Master services and variables. Corresponding information can be found in Annex K.

61131-9/WD V0.5 IEC 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3208 3209 11.8.2

179

Working Draft

Changing Device configuration including Data Storage

After each change of Device configuration/parameterization (CVID and/or CDID, see 9.2.2.2), the associated previously stored data set within the Master shall be cleared or marked invalid via the variable DS_Delete. 11.8.3 Parameter server (recipe)

The entire parameter sets of the Devices together with the Master parameters can be saved as "bulk" data within a parameter server of a higher level system. With the help of a parameter server PLC program controlled parameter change is possible, thus supporting flexible manufacturing. 11.8.4 Anonymous parameters

The parameter in the Direct Parameter page 2 can be supplied via field device description files in an "anonymous" manner. See corresponding fieldbus integration specifications that can be found in Annex K. 11.8.5 Virtual port mode DIwithSDCI

This optional operational mode provides a possibility to use a Device with SIO capability in the DIwithSDCI mode and allow the higher level system (for example PLC) to exchange Onrequest Data acyclically. Preferably, this will take place when parameters are to be changed, at production stop, or diagnosis intervals. This operational mode simplifies the control program due to the omission of configuration before and after an acyclic access. In principle the gateway application realizes this operational mode virtually. It is solely in a position to decide within the individual states what the next steps can be. The CM does not know this operational mode. The gateway application reads the configuration data hold by the CM and uses services from SM and AL to realize this operational mode. The following rules shall be observed when implementing DIwithSDCI: The DI signal of the Device is not valid during the acyclic access of the gateway application. It is likely that an invalid DI signal is detected very late. Thus, only after the next acyclic access an Event "PDInvalid" can be raised and wire break or Device replacement can be detected. The access will consume more time due to establishing communication and fallback procedures including Data Storage. The InspectionLevel shall at least comprise TYPE_COMP in order to detect an illegal Device.

The following state diagram in Figure 109 shows the individual states for the virtual operational mode DIwithSDCI.

Working Draft

180

61131-9/WD V0.5 IEC

/Initialization Idle_0 Service_rsp/ T10 Service_req/ T1 [InspLevel_LOW]/ T2

Check_Config_1

Build_Service_Resp_5

[InspLevel_OK]/ T3

DwS_Startup_2

[Error_any]/T4

[PreOperate]/ T5

DwS_Await_Resp_3

[Error_any]/T6

[Service_complete]/ T7 [Error_any]/T8 DwS_Fallback_4 [Fallback_OK]/T9

3210 3211 3212 3213 Figure 109 Virtual port mode "DIwithSDCI" Table 98 shows the states and transitions of the virtual port mode "DIwithSDCI". Table 98 State transitions of the state machine "DIwithSDCI"
STATE NAME Inactive_0 Check_Config_1 DwS_StartUp_2 DwS_Await_Resp_3 DwS_FallBack_4 Build_ServiceResp_5 STATE DESCRIPTION For the higher level control program the port is configured for the operational mode DIwithSDCI and waits on service requests. Within this state the InspectionLevel of the port is checked for a sufficient level. Within this state a complete startup until the PREOPERATE state is performed. This can include Data Storage and Event handling. Wait on responses (AL-Read.rsp or AL-Write.rsp). After accomplishing the services, the Device is switched back to the SIO mode via the MasterCommand "Fallback" and the port will be configured as a DI. The service response (positive or negative) will be created to finalize the service to the higher level control program. TARGET STATE 1 5 2 5 3 5 4 5 SM_SetPortConfig (to SDCI) SM_SetPortConfig (to DI) Start Service (AL_Read.req oder AL_Write.req) SM_SetPortConfig (to DI) SM_SetPortConfig (to DI) ACTION

3214
TRANSITION T1 T2 T3 T4 T5 T6 T7 T8 SOURCE STATE 0 1 1 2 2 3 3 4

61131-9/WD V0.5 IEC

TRANSITION T9 SOURCE STATE 4 5 TARGET STATE 5 0 TYPE Bool Bool Bool Bool Bool Bool

181
ACTION SM_SetPortConfig (to DI) DEFINITION

Working Draft

3215

T10

INTERNAL ITEMS InspLevel_LOW InspLevel_OK PreOperate Service_complete Fallback_OK Error_any

The necessary InspectionLevel is not configured in order to detect the correct Device. The necessary InspectionLevel is configured to detect the correct Device. State PREOPERATE is established The gateway application received AL_Read.rsp or AL_Write.rsp Fallback has been accomplished successfully Any error will quit this state

3216

Working Draft 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228

182

61131-9/WD V0.5 IEC

Annex A (normative) Codings, timing constraints, and errors

A.1
A.1.1

General structure and encoding of F-sequences

Overview

The general concept of F-sequences is outlined in 7.3.3.2. The following sections provide a detailed description of the individual elements of F-sequences. A.1.2 F-sequence control (FC)

The Master specifies the manner the user data are to be transmitted in an F-sequence control octet. This specification includes the transmission direction (read or write), the comunication channel, and the address (offset) of the data on the communication channel. The structure of the F-sequence control octet is illustrated in Figure A.1.
R/W Communication channel Address

3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3239 3240 Bit 0 to 4: Address These bits indicate the address, i.e. the octet offset of the user data on the specified communication channel (see also Table A.1). If an ISDU is selected via the communication channel value, these bits are used for flow control of the ISDU data. The address, which means in this case the position of the user data within the ISDU, is only available indirectly (see 7.3.6.2). Bit 5 to 6: Communication channel These bits indicate the communication channel for the access to the user data. The defined values for the communication channel parameter are listed in Table A.1. Table A.1 Values of communication channel
Value 0 1 2 3 Definition Process Page Diagnosis ISDU

Figure A.1 F-sequence control

3241 3242 3243 3244 3245 3246

Bit 7: R/W This bit indicates the transmission direction of the user data on the selected communication channel, i.e. read access (transmission of user data from Device to Master) or write access (transmission of user data from Master to Device). The defined values for the R/W parameter are listed in Table A.2. Table A.2 Values of R/W
Value 0 1 Definition Write access Read access

61131-9/WD V0.5 IEC 3247 3248 3249 3250 3251 3252

183

Working Draft

NOTE Generally, a Device is not obliged to support each and every of the 256 values of the F-sequence control octet. For read access to not implemented addresses or communication channels the value "0" is returned. A write access to not implemented addresses or communication channels shall be ignored.

A.1.3

Checksum / F-sequence type (CKT)

The F-sequence type is transmitted together with the checksum in the check/type octet. The structure of this octet is illustrated in Figure A.2.
F-sequence type Checksum

3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 Bit 0 to 5: Checksum These bits contain a 6 bit message checksum to ensure data integrity, see also A.1.6 and H.1. Bit 6 to 7: F-sequence type These bits indicate the F-sequence type. Herewith, the Master specifies how the messages within the F-sequence are structured. Defined values for the F-sequence type parameter are listed in Table A.3. Table A.3 Values of F-sequence types
Value 0 1 2 3 Type 0 Type 1 Type 2 (see NOTE) reserved Definition

Figure A.2 Checksum/F-sequence type octet

NOTE Subtypes depending on process data configuration and process data direction

3263 3264 3265 3266 3267 3268 3269 A.1.4 User data (PD or OD)

User data is a general term for both process data and on-request data. The length of user data can vary from 0 to 64 octets depending on F-sequence type and transmission direction (read/write). An overview of the available data types is shown in Table A.4. These data types can be arranged as records (different types) or arrays (same types). Table A.4 Data types for user data
Data type BooleanT UIntegerT IntegerT StringT OctetStringT Float32T TimeT TimeSpanT See E.2 See E.2.3 See E.2.4 See E.2.6 See E.2.7 See E.2.5 See E.2.8 See E.2.9 (IEC 61158-6) (IEC 61158-6) Reference

Working Draft 3270 3271 3272 3273 3274

184

61131-9/WD V0.5 IEC

The detailed coding of the data types can be found in Annex E. A.1.5 Checksum / status (CKS)

The checksum/status octet is part of the reply message from the Device to the Master. Its structure is illustrated in Figure A.3. It comprises a 6 bit checksum, a flag to indicate valid or invalid process data, and an event flag.
Event flag PD invalid

Checksum

3275 3276 3277 3278 3279 3280 3281 3282 3283 3284 3285 3286 3287 Bit 0 to 5: Checksum These bits contain a 6 bit checksum to ensure data integrity of the reply message. See also A.1.6 and H.1. Bit 6: PD invalid This bit represents a flag indicating that the Device cannot provide valid process data. Defined values for the parameter are listed in Table A.5. This flag shall be used for Devices with input process data. Devices with output process data shall always indicate process data valid. If the flag is set to process data invalid within one message, all the process input data of the complete process data cycle are invalid. Table A.5 Values of PD invalid
Value 0 1 Definition Process data valid Process data invalid

Figure A.3 Checksum/status octet

3288 3289 3290 3291 3292 3293 3294

Bit 7: Event flag This bit represents the event flag. It realizes a Device initiative for the data category "event" to be retrieved by the Master via the diagnosis communication channel (Table A.1). The Device can report events such as diagnosis information, failures, and errors via event response messages. Permissible values for the parameter are listed in Table A.6. Table A.6 Values of the event flag
Value 0 1 Definition No event Event

3295 3296 3297 3298 3299 3300 3301 A.1.6 Calculation of the checksum

The message checksum provides data integrity protection for data transmission from Master to Device and from Device to Master. Each UART character is protected by the UART parity bit Figure 17. Besides this individual character protection, all of the UART characters in a message are XOR (exclusive or) processed octet by octet. The check/type octet is included with checksum bits set to "0". The resulting checksum octet is compressed from 8 to 6 bit in

61131-9/WD V0.5 IEC 3302 3303 3304 3305 3306 3307 3308

185

Working Draft

accordance with the conversion procedure in Figure A.4 and its associated equations (A.1). The 6 bit compressed "Checksum6" is entered into the checksum/ F-sequence type octet ( Figure A.2). The same procedure takes place to secure the message from the Device to the Master. In this case the compressed checksum is entered into the checksum/status octet (Figure A.3). A seed value of 0x52 is used for the checksum calculation across the message. It is XORed with the first octet of the message (FC).
Seed value 0x52 0x52

+ +
XOR processing Checksum 8

FC CKT ... Message

+
Checksum 6

Octet n

3309 3310 3311 Figure A.4 Principle of the checksum calculation and compression The set of equations in (A.1) define the compression procedure from 8 to 6 bit in detail. D5 6 = D7 8 xor D5 8 xor D3 8 xor D1 8 D4 6 = D6 8 xor D4 8 xor D2 8 xor D0 8 D3 6 = D7 8 xor D6 8 D2 6 = D5 8 xor D4 8 D1 6 = D3 8 xor D2 8 D0 6 = D1 8 xor D0 8 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 (A.1)

A.2
A.2.1

F-sequence types
Overview

Process data and on-request data use separate cyclic and acyclic communication channels (Figure 6) to ensure scheduled and deterministic delivery of process data while delivery of onrequest data does not have consequences on the process data transmission performance. Within SDCI, F-sequences provide the access to the communication channels via the Fsequence Control octet. The number of different F-sequence types meets the various requirements of sensors and actuators regarding their process data width. See Figure 36 for an overview of the available F-sequence types that are described in the following sections. See A.2.6 for rules on how to use the F-sequence types. A.2.2 F-sequence TYPE_0

F-sequence TYPE_0 is mandatory for all Devices. F-sequence TYPE_0 only transmits on-request data. One octet of user data is read or written per cycle. This F-sequence is illustrated in Figure A.5.

Working Draft
TYPE 0 TYPE 0
Master read message Device reply message

186

61131-9/WD V0.5 IEC

FC

CKT OD CKS

Master write message Device reply message

FC

CKT

OD CKS

3327 3328 3329 3330 3331 A.2.3

Figure A.5 F-sequence TYPE_0 F-sequence TYPE_1_x

F-sequence TYPE_1_x is optional for all Devices. F-sequence TYPE_1_1 is illustrated in Figure A.6.
TYPE_1_1 TYPE_1_1
Master read message Device reply message FC CKT PD0 PD1 CKS

Master write message Device reply message

FC

CKT

PD0

PD1 CKS

3332 3333 3334 3335 3336 3337 3338 3339 3340 3341 3342

Figure A.6 F-sequence TYPE_1_1 Two octets of process data are read or written per cycle. Address (bit offset) belongs to the process communication channel (A.2.1). In case of interleave mode (7.3.4.2) and odd-numbered PD length the remaining octets within the frames are padded with 0x00. F-sequence TYPE_1_2 is illustrated in Figure A.7. Two octets of on-request data are read or written per cycle. For write access to on-request data via the page and diagnosis communication channels, only the first octet of on-request data is evaluated. The Device shall ignore the remaining octets. The Master shall send all other ODs with "0x00".

61131-9/WD V0.5 IEC

TYPE_1_2 TYPE_1_2
Master read message Device reply message

187

Working Draft

FC

CKT OD0 OD1 CKS

Master write message Device reply message

FC

CKT

OD0

OD1 CKS

3343 3344 3345 3346 3347 3348 3349

Figure A.7 F-sequence TYPE_1_2 F-sequence TYPE_1_V providing variable (extendable) frame length is illustrated in Figure A.8. A number of m octets of on-request data are read or written per cycle. For write access to on-request data via the page and diagnosis communication channels, only the first octet (OD 0 ) of on-request data is evaluated. The Device shall ignore the remaining octets. The Master shall send all other ODs with "0x00".
TYPE_1_V TYPE_1_V
Master read message Device reply message FC CKT OD0 ODm-1 CKS

Master write message Device reply message

FC

CKT

OD0

ODm-1 CKS

3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 A.2.4

Figure A.8 F-sequence TYPE_1_V F-sequence TYPE_2_x

F-sequence TYPE_2_x is optional for all Devices. F-sequences TYPE_2_1 through TYPE_2_6 are defined. F-sequence TYPE_2_V provides variable (extendable) frame length. F-sequence TYPE_2_x transmits process data and on-request data in one message. The number of process and on-request data read or written in each cycle depends on the type. The Address parameter (Figure A.1) belongs in this case to the on-request communication channel. The process data address is specified implicitly starting at "0". The format of process data is characterizing the F-sequence TYPE_2_x. F-sequence TYPE_2_1 transmits one octet of read process data and one octet of read or write on-request data per cycle. This F-sequence type is illustrated in Figure A.9.

Working Draft
TYPE_2_1 TYPE_2_1
Master read message Device reply message

188

61131-9/WD V0.5 IEC

FC

CKT OD PD CKS

Master write message Device reply message

FC

CKT

OD PD CKS

3362 3363 3364 3365

Figure A.9 F-sequence TYPE_2_1 F-sequence TYPE_2_2 transmits 2 octets of read process data and one octet of on-request data per cycle. This F-sequence type is illustrated in Figure A.10.
TYPE_2_2 TYPE_2_2
Master read message Device reply message FC CKT OD PD0 PD1 CKS

Master write message Device reply message

FC

CKT

OD PD0 PD1 CKS

3366 3367 3368 3369

Figure A.10 F-sequence TYPE_2_2 F-sequence TYPE_2_3 transmits one octet of write process data and one octet of read or write on-reqest data per cycle. This F-sequence type is illustrated in Figure A.11.
TYPE_2_3 TYPE_2_3
Master read message Device reply message FC CKT PD OD CKS

Master write message Device reply message

FC

CKT

PD

OD CKS

3370 3371 3372 3373

Figure A.11 F-sequence TYPE_2_3 F-sequence TYPE_2_4 transmits 2 octets of write process data and one octet of read or write on-request data per cycle. This F-sequence type is illustrated in Figure A.12

61131-9/WD V0.5 IEC

TYPE_2_4 TYPE_2_4
Master read message Device reply message FC

189

Working Draft

CKT

PD0

PD1 OD CKS

Master write message Device reply message

FC

CKT

PD0

PD1

OD CKS

3374 3375 3376 3377

Figure A.12 F-sequence TYPE_2_4 F-sequence TYPE_2_5 transmits one octet of write and read process data and one octet of read or write on-request data per cycle. This F-sequence type is illustrated in Figure A.13.
TYPE_2_5 TYPE_2_5
Master read message Device reply message FC CKT PD OD PD CKS

Master write message Device reply message

FC

CKT

PD

OD PD CKS

3378 3379 3380 3381

Figure A.13 F-sequence TYPE_2_5 F-sequence TYPE_2_6 transmits 2 octets of write and read process data and one octet of read or write on-request data per cycle. This F-sequence type is illustrated in Figure A.14.
TYPE_2_6 TYPE_2_6
Master read message Device reply message FC CKT PD0 PD1 OD PD0 PD1 CKS

Master write message Device reply message

FC

CKT

PD0

PD1

OD PD0 PD1 CKS

3382 3383 3384 3385 3386 3387 3388

Figure A.14 F-sequence TYPE_2_6 F-sequence TYPE_2_V transmits the entire write (read) ProcessDataIn n (k) octets per cycle. The range of n (k) is 0 to 32. Either PDin or PDout are not existing when n=0 or k=0. TYPE_2_V also transmits m octets of (segmented) read or write on-request data per cycle using the address in Figure A.1. Permitted values for m are 1, 2, 8, and 32. This variable Fsequence type is illustrated in Figure A.15.

Working Draft

190

61131-9/WD V0.5 IEC

TYPE_2_V TYPE_2_V
Master read message FC CKT PD0 PDn-1 OD0 ODm-1 PD0 PDk-1 CKS

Device reply message

Master write message

FC

CKT

PD0

PDn-1

OD0

ODm-1 PD0 PDk-1 CKS

Device reply message

3389 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 Figure A.15 F-sequence TYPE_2_V For write access to on-request data via the page and diagnosis communication channels, only the first octet (OD 0 ) of on-request data is evaluated. The Device shall ignore the remaining octets. The Master shall send all other ODs with "0". A.2.5 F-sequence type 3

F-sequence type 3 is reserved and shall not be used. A.2.6 F-sequence type usage for STARTUP, PREOPERATE and OPERATE modes

Table A.8 shows the F-sequence types for the STARTUP mode together with the minimum cycle time (T initcyc ) to be observed for Master implementations. Table A.7 F-sequence types for the STARTUP mode
F-sequence Capability n/a 1 On-request data Octets TYPE_0 100 F-sequence type Minimum cycle time T BIT

3400 3401 3402 3403 Table A.8 shows the F-sequence types for the PREOPERATE mode together with the minimum cycle time (T initcyc ) to be observed for Master implementations. Table A.8 F-sequence types for the PREOPERATE mode
F-sequence Capability 0 1 2 3 NOTE 1 2 8 32 On-request data Octets TYPE_0 TYPE_1_2 TYPE_1_V TYPE_1_V 100 100 210 550 F-sequence type Minimum cycle time T BIT

The minimum cycle time in PREOPERATE mode is a requirement for the Master.

3404 3405 3406 3407 Table A.9 shows the F-sequence types for the OPERATE mode for legacy Devices according to [13]. The minimum cycle time for Master in OPERATE mode is defined by the parameter "MinCycleTime" of the Device (see B.1.4).

61131-9/WD V0.5 IEC 3408

191

Working Draft

Table A.9 F-sequence types for the OPERATE mode (V1.0)

F-sequence Capability 0 1 * * * * * * * Key On-request Data Octets 1 2 2 2 1 1 1 1 1 * = don't care 0 0 332 octets 032 octets 18 bit 916 bit 0 0 18 bit Process Data (PD) PDin 0 0 032 octets 332 octets 0 0 18 bit 916 bit 18 bit PDout F-sequence type V1.0 [13] TYPE_0 TYPE_1_2 TYPE_1_1/1_2 interleaved TYPE_1_1/1_2 interleaved TYPE_2_1 TYPE_2_2 TYPE_2_3 TYPE_2_4 TYPE_2_5

3409 3410 3411 3412 3413

F-sequence Capability 0 1 6 7 0 0 0 0 0 0 0 0 0 4 4 5 5 6 6 7 7

Table A.10 shows the F-sequence types for the OPERATE mode for Devices according to this specification. The minimum cycle time for Master in OPERATE mode is defined by the parameter MinCycleTime of the Device (see B.1.4). Table A.10 F-sequence types for the OPERATE mode
On-request Data Octets 1 2 8 32 2 2 1 1 1 1 1 1 1 1 1 2 2 8 8 32 32 0 0 0 0 332 octets 032 octets 18 bit 916 bit 0 0 18 bit 916 bit 116 bit 032 octets 332 octets >0 bit, octets 0 bit, octets >0 bit, octets 0 bit, octets >0 bit, octets 0 bit, octets Process Data (PD) PDin 0 0 0 0 032 octets 332 octets 0 0 18 bit 916 bit 18 bit 116 bit 916 bit 332 octets 032 octets 0 bit, octets >0 bit, octets 0 bit, octets >0 bit, octets 0 bit, octets >0 bit, octets PDout TYPE_0 TYPE_1_2 TYPE_1_V TYPE_1_V TYPE_1_1/1_2 interleaved (see NOTE) TYPE_1_1/1_2 interleaved (see NOTE) TYPE_2_1 TYPE_2_2 TYPE_2_3 TYPE_2_4 TYPE_2_5 TYPE_2_6 TYPE_2_6 TYPE_2_V TYPE_2_V TYPE_2_V TYPE_2_V TYPE_2_V TYPE_2_V TYPE_2_V TYPE_2_V F-sequence type

Working Draft
F-sequence Capability On-request Data Octets

192
Process Data (PD) PDin PDout

61131-9/WD V0.5 IEC

F-sequence type

NOTE The interleave mode is not recommended for new developments of Devices. It is intended to not support this mode in future releases

3414 3415 3416 3417 3418 3419 3420 3421

A.3
A.3.1

Timing constraints
General

The interactions of a Master and its Device are characterized by a cycle time. This time includes the F-sequence duration and a subsequent idle time (T idle ). A.3.2 Bit time

The bit time T BIT is the time it takes to transmit a single bit. It is the inverse value of the transmission rate (A.2). T BIT = 1/(transmission rate) (A.2)

3422 3423 3424 3425 3426

Values for T BIT are specified in Table 7. A.3.3 Character transmission delay of Master (ports)

The character transmission delay t 1 of a port is the duration of the pause between the end of the stop bit of a UART character and the beginning of the start bit of the next UART character. The port shall transmit the UART characters within a maximum pause of 1 bit time (A.3). 0 t 1 1 T BIT (A.3)

3427 3428 3429 3430

A.3.4

Character transmission delay of Devices

The Devices character transmission delay t 2 is the duration of the pause between the end of the stop bit of a UART character and the beginning of the start bit of the next UART character. The Device shall transmit the UART characters within a maximum pause of 3 bit times (A.4). 0 t 2 3 T BIT (A.4)

3431 3432 3433 3434 3435

A.3.5

Response time of Devices

The Device's response time t A is the duration of the pause between the end of the stop bit of a port's last UART character being received and the beginning of the start bit of the first UART character being sent. The Device shall observe a pause of at least 1 bit time but no more than 10 bit times (A.5). 1 T BIT t A 10 T BIT (A.5)

3436 3437 3438

A.3.6

F-sequence time

Communication between a port and and its associated Device takes place in a fixed schedule, called the F-sequence time (A.6). t
F-sequence

= (m+n) * 11 * T BIT + t A + (m-1) * t 1 + (n-1) * t 2

(A.6)

61131-9/WD V0.5 IEC 3439 3440 3441 3442 3443

193

Working Draft

where m is the number of UART characters sent by the port to the Device and n is the number of UART characters sent by the Device to the port. The formula can only be used for estimates as the times t 1 and t 2 may not be constant. Figure A.16 illustrates the timings of an F-sequence consisting of a Master (port) message and a Device message.
Port (Master) UART character UART character UART character

t1
Device

t1

UART character

UART character

UART character

t2 tA

t2

3444 3445 3446 3447 3448 A.3.7 Cycle time

tF-sequence

Figure A.16 F-sequence timing

The cycle time t CYC (A.7) is depending on the Device's parameter MinCycleTime and the design and implementation of a Master and the number of ports. t CYC = t
F-sequence

+ t idle

(A.7)

3449 3450 3451 3452 3453 3454 3455

The adjustable Device parameter MasterCycleTime can be used for the design of a Device specific technology such as an actuator to derive the timing conditions for a de-activated or de-energized state. Table A.11 shows recommended minimum cycle time values to be used as a setpoint for the specified transmission rate of a port. The values are calculated based on F-sequence Type_2_1. Table A.11 Recommended MinCycleTimes
Transmission rate COM1 COM2 COM3 t CYC 18,0 ms 2,3 ms 0,4 ms

3456 3457 3458 3459 3460

A.3.8

Idle time

The idle time t idle results from the configured cycle time t CYC and the F-sequence time t F-sequence . With reference to a port, it includes the time between the end of the message of a Device and the beginning of the next message from the Master (port).
NOTE The idle time shall be long enough for the Device to become ready to receive the next message.

Working Draft 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3479 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3490 3491 3492 3493 3494 3495

194

61131-9/WD V0.5 IEC

A.4
A.4.1

Errors and remedies

UART errors Parity errors

A.4.1.1

Both the UART parity bit (Figure 17) and the checksum (A.1.6) are two independent mechanisms to secure the data transfer. This means that duplicate bit errors in different octets of a message resulting in the correct checksum can also be detected. Both mechanisms lead to the same error processing. Remedy: The Master shall repeat the Master message 2 times (see 7.2.2.1). Devices shall reject all corrupted data and create no reaction. A.4.1.2 UART framing errors

The conditions for the correct detection of a UART frame are described in 5.3.3.2. Error processing shall take place, whenever wrong signal shapes or timings lead to a UART framing error. Remedy: See A.4.1.1. A.4.2 Wake-up errors

The wake-up current pulse is described in 5.3.3.3 and the wake-up procedures in 7.3.2.1. Several faults may occcur during the attempts to establish communication. Remedy: Retries are possible. See 7.3.2.1 for details. A.4.3 A.4.3.1 Transmission errors Checksum errors

The checksum mechanism is described in A.1.6. Any checksum error leads to an error processing. Remedy: See A.4.1.1. A.4.3.2 Timeout errors

The diverse timing constraints with F-sequences are defined in A.3. Master (ports) and Devices are checking several critical timings such as lack of synchronism within messages. Remedy: See A.4.1.1. A.4.3.3 Collisions

A collision occurs whenever the Master and Device are sending simultaneously due to an error. This error is interpreted as a faulty F-sequence. Remedy: See A.4.1.1. A.4.4 Protocol errors

A protocol error occurs for example whenever the sequence of the segmented transmission of an ISDU is wrong (flow control case in A.1.2). Remedy: Abort of service with ErrorType information (Annex C).

61131-9/WD V0.5 IEC 3496 3497 3498 3499 3500

195

Working Draft

A.5
A.5.1

General structure and encoding of ISDUs

Overview

The purpose and general structure of an ISDU is outlined in 7.3.6.1. The following sections provide a detailed description of the individual elements of an ISDU and some examples. A.5.2 Service
Service Length

3501 3502 3503 3504 3505 3506 3507 3508

Service (binary) 0000 0001 0010 0011 0100 0101 0110 0111 1000 1001 1010 1011 1100 1101 1110 1111

Figure A.17 Service octet Bits 0 to 3: Length The encoding of the nibble Length of the ISDU is defined in Table A.14 . Bits 4 to 7: Service The encoding of the nibble Service of the ISDU is defined in Table A.12. All other elements of the structure defined in 7.3.6.1 are transmitted as independent octets. Table A.12 Definition of the nibble "Service"
Definition Master No Service Write Request Write Request Write Request Reserved Reserved Reserved Reserved Reserved Read Request Read Request Read Request Reserved Reserved Reserved Reserved Device No Service Reserved Reserved Reserved Write Response (-) Write Response (+) Reserved Reserved Reserved Reserved Reserved Reserved Read Response (-) Read Response (+) Reserved Reserved 8-bit Index 8-bit Index and Subindex 16-bit Index and Subindex none none n/a 8-bit Index 8-bit Index and Subindex 16-bit Index and Subindex none none Index format

3509 3510 Table A.13 defines the syntax of the ISDUs. ErrorType can be found in Annex C.

Working Draft 3511

ISDU name Write Request

196 Table A.13 ISDU syntax

ISDU structure

61131-9/WD V0.5 IEC

{Service(0x1), LEN, Index, [Data*], CHKPDU} ^ {Service(0x2), LEN, Index, Subindex, [Data*], CHKPDU} ^ {Service(0x3), LEN, Index, Index, Subindex, [Data*], CHKPDU} Service(0x5), Length(0x2), CHKPDU Service(0x4), Length(0x4), ErrorType, CHKPDU {Service(0x9), Length(0x3), Index, CHKPDU} ^ {Service(0xA), Length(0x4), Index, Subindex, CHKPDU} ^ {Service(0xB), Length(0x5), Index, Index, Subindex, CHKPDU} Service(0xD), LEN, [Data*], CHKPDU Service(0xC), Length(0x4), ErrorType, CHKPDU

Write Response (+) Write Response (-) Read Request

Read Response (+) Read Response (-) Key

LEN = {Length(0x1), ExtLength} ^ {Length}

3512 3513 3514 3515 3516 3517 3518 A.5.3 Extended length (ExtLength)

The number of octets transmitted in this service, including all protocol information (6 octets), is specified in the Length element of an ISDU. If the total length is more than 15 octets, the length is specified using extended length information ("ExtLength"). Permissible values for Length and "ExtLength" are listed in Table A.14. Table A.14 Definition of nibble Length and octet ExtLength
Service 0 0 0 1 to 15 1 to 15 1 to 15 1 to 15 1 to 15 Length 0 1 2 to 15 0 1 1 1 2 to 15 ExtLength n/a n/a n/a n/a 0 to 16 17 to 238 239 to 255 n/a Definition No service, ISDU length is 1. Protocol use. Device busy, ISDU length is 1. Protocol use. Reserved and shall not be used Reserved and shall not be used Reserved and shall not be used Length of ISDU in "ExtLength" Reserved and shall not be used Length of ISDU

3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 A.5.4 Index and Subindex

The parameter address of the data object to be transmitted using the ISDU is specified in the Index element. Index has a range of values from 0 to 65 535 (see B.2.1 for constraints). Index values 0 and 1 shall be rejected by the Device. There is no need for the Device to support all Index and Subindex values. The Device shall send a negative response to Index or Subindex values not supported. The data element address of a structured parameter of the data object to be transmitted using the ISDU is specified in the Subindex element. Subindex has a range of values from 0 to 255, whereby a value of "0" is used to reference the entire data object (Figure 4). Table A.15 shows the Index formats used in the ISDU depending on the parameters transmitted.

61131-9/WD V0.5 IEC 3531

Index 0 to 255 0 to 255 256 to 65 535

197 Table A.15 Use of Index formats

Subindex 0 1 to 255 0 to 255 8 bit Index 8 bit Index and 8 bit Subindex 16-bit Index and 8 bit Subindex (see NOTE) Index format of ISDU

Working Draft

NOTE See B.2.1 for constraints on the Index range

3532 3533 3534 3535 3536 3537 3538 3539 3540 A.5.5 Data

The Data element can contain the data objects described in Annex B or Device specific data objects respectively. The data length corresponds to the entries in the Length element minus the protocol frame. A.5.6 Check ISDU (CHKPDU)

The CHKPDU element provides data integrity protection. The sender calculates the value of "CHKPDU" by XOR processing all of the octets of an ISDU, including "CHKPDU" with a preliminary value "0", which is then replaced by the result of the calculation (Figure A.18).
Sender Service Length Receiver Service Length

ExtLength Index Subindex Data 1 ... Data n 1. CHKPDU = "0" 2. CHKPDU = Checksum Prior to sending

+ + + + + + +

XOR

ExtLength Index Subindex Data 1 ... Data n CHKPDU = Checksum

+ + + + + + +

XOR

3541 3542 3543 3544 3545 3546 3547 3548

Checksum Checksum

Result = "0", otherwise perturbed bits Result = "0", otherwise perturbed bits

Figure A.18 Check of ISDU integrity via CHKPDU The receiver checks whether XOR processing of all of the octets of the ISDU will lead to the result "0" (see Figure A.18). If the result is <> "0", error processing shall take place. See also A.1.6. A.5.7 ISDU examples

Figure A.19 illustrates typical examples of request formats for ISDUs, which are explained in the following sections.

Working Draft
Request example 1 Service 0101 Request example 2 Service 0110

198
Request example 3 Service 0111

61131-9/WD V0.5 IEC

Request example 4 Service 0001
1)

Request example 5 0000 0000

Index Data 1 (MSO) Data 2 (LSO) CHKPDU 8 Bit Index

Index Subindex Data 1 Data 2 CHKPDU 8 Bit Index and Subindex

Index Index Subindex Data 1 Data 2 CHKPDU 16 Bit Index and Subindex

ExtLength (n) Index Data 1 Data 2 ... ... Data (n-4) CHKPDU

"Idle" request

3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559 3560 3561 3562 3563 3564 3565 3566 3567

1) Overall ISDU ExtLength = n (1 to 238); Length = 1 ("0001")

Figure A.19 Examples of request formats for ISDUs The ISDU request in example 1 comprises one Index element allowing addressing from 0 to 254 (Table A.15). The Subindex is supposed to be "0". Thus, the whole content of Index is Data 1 with the most significant octet (MSO) and Data 2 with the least significant octet (LSO) according to Figure 1. The total length is 5 ("0101"). The ISDU request in example 2 comprises one Index element allowing addressing from 0 to 254 and the Subindex element allowing addressing an element of a data structure. The total length is 6 ("0110"). The ISDU request in example 3 comprises two Index elements allowing to address from 256 to 65 535 (Table A.15) and the Subindex element allowing to address an element of a data structure. The total length is 7 ("0111"). The ISDU request in example 4 comprises one Index element and the ExtLength element indicating the number of ISDU elements (n), permitting numbers from 17 to 238. In this case the Length element has the value "1". The ISDU request "Idle" in example 5 should be used as a "keep alive" message in order to detect any communication interrupts. Figure A.20 illustrates typical examples of response ISDUs, which are explained in the following sections
Response example 1 Service 0010 1) Response example 2 Service 0100 Response example 3 Service 0001
2)

Response example 4 0000 0001

CHKPDU

Data 1 (MSO) Data 2 (LSO) CHKPDU

ExtLength (n) Data 1 Data 2 ... ... Data (n-3) CHKPDU

"Busy" response

3568 3569 3570

1) Minimum length = 2 ("0010") 2) Overall ISDU ExtLength = n (17 to 238); Length = 1 ("0001")

Figure A.20 Examples of response ISDUs The ISDU response in example 1 shows the minimum value 2 for the Length element ("0010").

61131-9/WD V0.5 IEC 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580

199

Working Draft

The ISDU response in example 2 shows two Data elements and a total number of 4 elements in the Length element ("0100"). Data 1 carries the most significant octet (MSO) and Data 2 the least significant octet (LSO) according to Figure 1. The ISDU response in example 3 shows the ExtLength element indicating the number of ISDU elements (n), permitting numbers from 17 to 238. In this case the Length element has the value "1". The ISDU response "Busy" in example 4 should be used as a "keep alive" response of a Device to an "Idle" request of the Master in order to detect any communication interrupts. Figure A.21 illustrates a typical example of both a read and a write request ISDU, which are explained in the following sections.
Read.req (Index) 1001 Index CHKPDU 0011 Read.res (+, Data) 1101 0100 or Read.res (-, Error) 1100 0100

Data 1 (MSO) Data 2 (LSO) CHKPDU

ErrorCode AdditionalCode CHKPDU Write.res (-, Error)

Write.req (Index, Data) 0010 Index Subindex Data 1 (MSO) Data 2 (LSO) CHKPDU 0110

Write.res (+) 0101 0010 or

0100

0100

CHKPDU

ErrorCode AdditionalCode CHKPDU

3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597

Figure A.21 Examples of read and write request ISDUs The code of the read request service is "1001". According to Table A.13 this comprises an Index element. A successful read response (+) of the Device with code "1101" is shown next to the request with two Data elements. Total length is 4 ("0100"). An unsuccessful read response (-) of the Device with code "1100" is shown next in line. It carries the ErrorType with the two Data elements ErrorCode and AdditionalCode (Annex C). The code of the write request service is "0010". According to Table A.13 this comprises an Index and a Subindex element. A successful write response (+) of the Device with code "0101" is shown next to the request with no Data elements. Total length is 2 ("0010"). An unsuccessful read response (-) of the Device with code "0100" is shown next in line. It carries the ErrorType with the two Data elements ErrorCode and AdditionalCode (Annex C).

A.6
A.6.1

General structure and encoding of events

General

In 7.3.8.1 and Table 50 the purpose and general structure of the event buffer is described. This buffer accommodates a StatusCode, several EventQualifiers and their associated EventCodes. The coding of these buffer elements is defined in the subsequent sections.

Working Draft 3598 3599 3600 3601 A.6.2 StatusCode type 1 (no details)

200

61131-9/WD V0.5 IEC

Existing sensor or actuator Devices may have implemented a StatusCode type 1 that shall not be used for new Device developments. However, all Master shall support this StatusCode type 1 also. Figure A.22 shows the structure of this StatusCode.
PD Invalid

Details

Reserv.

Event Code (type 1)

3602 3603 3604 3605 3606 3607 Figure A.22 Structure of StatusCode type 1 Bits 0 to 4: EventCode (type 1) The coding of this data structure is listed in Table A.16. The EventCodes are mapped into EventCodes (type 2) as listed in Annex D. See 7.3.8.2 for additional information. Table A.16 Mapping of EventCodes (type 1)
EventCode (type 1) ****1 ***1* **1** *1*** 1**** Key * type 2 EventCode (type2) 0xFF80 0xFF80 0x6320 0xFF80 0xFF10 Instance Application Application Application Application Application Type Notification Warning Error Error Error Mode Event single shot Event single shot Event single shot Event single shot Event single shot

Don't care See Table D.1 and Table D.2

3608 3609 3610 3611 3612 3613 3614 3615 3616 3617

Bit 5: Reserved This bit is reserved and shall be set to zero in StatusCode type 1. Bit 6: Reserved
NOTE This bit is used in V1.0 for PDinvalid indication

Bit 7: Event Details This bit indicates that no detailed event information is available. It shall always be set to zero in StatusCode type 1. A.6.3 StatusCode type 2 (with details)

Figure A.23 shows the structure of the StatusCode type 2.

Details Reserv. Activated events

3618 3619 3620 3621 3622 3623 3624 Figure A.23 Structure of StatusCode type 2 Bits 0 to 5: Activated Events Each bit is linked to an event in the buffer (7.3.8.1) as demonstrated in Figure A.24. Bit 0 is linked to event 1, bit 1 to event 2, etc. A bit with value "1" indicates that the corresponding EventQualifier and the EventCode have been entered in valid formats in the buffer. A bit with value "0" indicates an invalid entry.

61131-9/WD V0.5 IEC

201
Details Reserv.

Working Draft
5
Activated events

StatusCode (type 2)

EventQualifier and EventCode 1 EventQualifier and EventCode 2 EventQualifier and EventCode 3 EventQualifier and EventCode 4 EventQualifier and EventCode 5

3625 3626 3627 3628 3629 3630 3631 3632 3633 3634

EventQualifier and EventCode 6

Figure A.24 Indication of activated events Bit 6: Reserved This bit is reserved and shall be set to zero.
NOTE This bit is used in the legacy protocol version V1.0 [13] for PDinvalid indication

Bit 7: Event Details This bit indicates that detailed event information is available. It shall always be set in StatusCode type 2. A.6.4 EventQualifier

The EventQualifier is illustrated in Figure A.25.

MODE TYPE SOURCE INSTANCE

3635 3636 3637 3638 3639 3640 3641 Table A.17 Values of INSTANCE
Value 0 1 2 3 4 5 to 7 Unknown PL DL AL Application Reserved Definition

Figure A.25 Structure of the EventQualifier Bits 0 to 2: INSTANCE These bits indicate the particular source (instance) of an Event thus refining its evaluation on the receiver side. Permissible values for INSTANCE are listed in Table A.17.

Working Draft 3642 3643 3644 3645 3646

202

61131-9/WD V0.5 IEC

Bit 3: SOURCE This bit indicates the source of the Event. Permissible values for SOURCE are listed in Table A.18. Table A.18 Values of SOURCE
Value 0 1 Definition Device application (remote) Master application (local)

3647 3648 3649 3650

Bits 4 to 5: TYPE These bits indicate the event category. Permissible values for TYPE are listed in Table A.19. Table A.19 Values of TYPE
Value 0 1 2 3 Definition Reserved Notification Warning Error

3651 3652 3653 3654

Bits 6 to 7: MODE These bits indicate the event mode. Permissible values for MODE are listed in Table A.20. Table A.20 Values of MODE
Value 0 1 2 3 Definition reserved Event single shot Event disappears Event appears

3655 3656 3657 3658 A.6.5 EventCode

The EventCode entry contains the identifier of an actual event. Permissible values for EventCode are listed in Annex D.

61131-9/WD V0.5 IEC 3659 3660 3661 3662 3663 3664 3665 3666 3667 3668 3669 3670

203

Working Draft

Annex B (normative) Parameter and commands

B.1
B.1.1

Direct parameter page 1 and 2

Overview

In principle, the designer of a Device has a large amount of space for parameters and commands as shown in Figure 4. However, small sensors with a limited number of parameters and limited resources are striving for a simple subset. SDCI offers the so-called direct parameter pages 1 and 2 with a simplified access method (page communication channel according Table A.1) to meet this requirement. The range of direct parameters is structured as shown in Figure B.1. It is split into page 1 and page 2.
Direct parameter
Page 2: Device (individual or profile)

Device specific 0x10 0x1F

Page 1: System and predefined parameters and controls (fixed)

Application control 0x0F Identification 0x07 0x0E Communication control 0x00 0x06

3671 3672 3673 3674 3675 3676 3677 3678 3679 3680 3681 3682 3683 3684 3685 3686 Figure B.1 Classification and mapping of direct parameters Page 1 ranges from 0x00 to 0x0F. It comprises the following categories of parameters: Communication control Identification parameter Application control

The Master application layer (AL) provides read only access to direct parameter page 1 in form of data objects (8.2.1) via Index 0. Single octets can be read via Index 0 and the corresponding Subindex. Subindex 1 indicates address 0x00 and Subindex 16 address 0x0F. Page 2 ranges from 0x10 to 0x1F. This page comprises parameters optionally used by the individual Device technology. The Master application layer (AL) provides read/write access to direct parameter page 2 in form of data objects (8.2.1) via Index 1. Single octets can be written or read via Index 1 and the corresponding Subindex. Subindex 1 indicates address 0x10 and Subindex 16 address 0x1F. A Device shall always return the value 0 upon a read access to direct parameter addresses, which are not implemented (for example in case of reserved parameter addresses or not

Working Draft 3687 3688 3689

Address Parameter name

204

61131-9/WD V0.5 IEC

supported optional parameters). The Device shall ignore a write access to not implemented parameters. Table B.1 Direct parameter page 1 and 2
Access Implementation /reference Description

Direct parameter page 1 0x00 0x01 MasterCommand MasterCycleTime MinCycleTime W R/W Mandatory/ B.1.2 Mandatory/ B.1.3 Mandatory/ B.1.4 Mandatory/ B.1.5 Mandatory/ B.1.6 Mandatory/ B.1.7 Mandatory/ B.1.8 Mandatory/ B.1.9 Master command to switch to operating states (see NOTE) Actual cycle duration used by the Master to address the Device. Can be used as a parameter to monitor process data transfer. Minimum cycle duration supported by a Device. This is a performance feature of the Device and depends on its technology and implementation. Information about implemented options related to F-sequences and physical configuration ID of the used protocol version for implementation (shall be set to 0x11) Number and structure of input data (process data from Device to Master) Number and structure of output data (process data from Master to Device) Unique vendor identification (see Annex K for support)

0x02

0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A 0x0B 0x0C 0x0D 0x0E 0x0F

F-sequence Capability RevisionID ProcessDataIn ProcessDataOut VendorID 1 (MSB) VendorID 2 (LSB) DeviceID 1 (Octet 2,MSB) DeviceID 2 (Octet 1) DeviceID 3 (Ocet 0, LSB) FunctionID 1 (MSB) FunctionID 2 (LSB)

R R/W R R R

R/W

Mandatory/ B.1.10

Unique Device identification allocated by a vendor

B.1.11

Reserved (Engineering shall set both octets to "0x00")

R SystemCommand W

reserved Optional/ B.1.12 Command interface for end user applications only and Devices without ISDU support (see NOTE)

Direct parameter page 2 0x10 0x1F Vendor specific Optional Optional/ B.1.13 Device specific parameters

NOTE A read operation returns undefined values

3690 3691 3692 3693 3694 B.1.2 MasterCommand

The Master application is able to check the status of a Device or to control its behaviour with the help of MasterCommands (7.3.7). Permissible values for these parameters are defined in Table B.2.

61131-9/WD V0.5 IEC 3695

Value 0x00 to 0x59 0x5A

205 Table B.2 Types of MasterCommands

Working Draft

MasterCommand Reserved Fallback

Description

Transition from communication to SIO mode. The Device shall execute this transition after 3 Master-CycleTimes and or before 500 ms elapsed after the MasterCommand.

0x5B to 0x94 0x95 0x96 0x97 0x98 0x99 0x9A 0x9B to 0xFF

Reserved MasterIdent DeviceIdent DeviceStartup ProcessDataOutputOperate DeviceOperate DevicePreoperate Reserved Indicates a Master revision higher than 1.0 Start check of direct parameter page for changed entries Switches the Device from OPERATE or PREOPERATE to STARTUP Process output data valid Process output data invalid or not available. Switches the Device from STARTUP or PREOPERATE to OPERATE Switches the Device from STARTUP to state PREOPERATE

3696 3697 3698 3699 3700 3701 3702 3703 B.1.3 MasterCycleTime

This is a Master property and sets up the actual cycle time of a particular port. See A.3.7 for the application of the MasterCycleTime and B.1.4 for the coding and for the definition of the time base. B.1.4 MinCycleTime

See A.3.7 for the application of the MinCycleTime. The structure of the MinCycleTime parameter is illustrated in Figure B.2.
Time base Multiplier

3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 Bits 0 to 5: Multiplier These bits contain a 6-bit multiplier for the calculation of the MinCycleTime. Permissible values for the multiplier are 0 to 63. Bits 6 to 7: Time Base These bits contain the time base for the calculation of the MinCycleTime. With a value of 0x00 assigned to this octet, the Device will not be restricted regarding the cycle time (i.e. Device has no MinCycleTime). In this case the Master shall use the calculated worst case F-sequence timing (A.3.6). The permissible combinations for time base and multiplier are listed in Table B.3 along with the resulting values for MinCycleTime. Figure B.2 MinCycleTime

Working Draft 3716

Code (binary) 00 01 10 11

206

61131-9/WD V0.5 IEC

Table B.3 Possible values of MinCycleTime

Time Base 0,1 ms 0,4 ms 1,6 ms Reserved Calculation Multiplier * Time Base 6,4 ms + Multiplier * Time Base 32,0 ms + Multiplier * Time Base Reserved Cycle Time 0,4 ms to 6,3 ms 6,4 ms to 31,6 ms 32,0 ms to 132,8 ms Reserved

3717 3718 3719 B.1.5 F-sequence Capability

The structure of the F-sequence Capability parameter is illustrated in Figure B.3.

PREOPERATE F-sequence type OPERATE F-sequence type

Reserved

ISDU

3720 3721 3722 3723 3724 3725 Bit 0: ISDU This bit indicates whether or not the ISDU communication channel is supported. Permissible values for ISDU are listed in Table B.4. Table B.4 Values of ISDU
Value 0 1 Definition ISDU not supported ISDU supported

Figure B.3 F-sequence Capability

3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 Bits 1 to 3: OPERATE F-sequence type This parameter indicates the available F-sequence type during the OPERATE state. Permissible values for the OPERATE F-sequence type are listed in Table A.9 for legacy Devices according to [13] and in Table A.10 for Devices according to this specification. Bits 4 to 5: PREOPERATE F-sequence type This parameter indicates the available F-sequence type during the PREOPERATE state. Permissible values for the PREOPERATE F-sequence type are listed in Table A.8. Bits 6 to 7: Reserved These bits are reserved and shall be set to zero in this version of the specification. B.1.6 RevisionID (RID)

The RevisionID parameter is the two-digit version number of the SDCI protocol implemented within the Device. Its structure is illustrated in Figure B.4. The RevisionID can be overwritten (10.6.3). An accepted different RevisionID shall be volatile. The legacy protocol version 1.0 is defined in [13]. This specification defines version 1.1.

61131-9/WD V0.5 IEC

MajorRev

207
MinorRev

Working Draft

3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 Bits 0 to 3: MinorRev These bits contain the minor digit of the version number, for example 0 for the protocol version 1.0. Permissible values for MinorRev are 0x0 to 0xF. Bits 4 to 7: MajorRev These bits contain the major digit of the version number, for example 1 for the protocol version 1.0. Permissible values for MajorRev are 0x0 to 0xF. B.1.7 ProcessDataIn Figure B.4 RevisionID

The structure of the ProcessDataIn parameter is illustrated in Figure B.5.

BYTE SIO Reserve Length

3751 3752 3753 3754 3755 3756 3757 3758 3759 3760 3761 3762 Bits 0 to 4: Length These bits contain the length of the input data (process data from Device to Master) in the length unit designated in the BYTE parameter bit. Permissible codes for Length are defined in Table B.6. Bit 5: Reserve This bit is reserved and shall be set to zero in this version of the specification. Bit 6: SIO This bit indicates whether the Device provides a switching signal in SIO mode. Permissible values for SIO are listed in Table B.5. Table B.5 Values of SIO
Value 0 1 Definition SIO mode not supported SIO mode supported

Figure B.5 ProcessDataIn

3763 3764 3765 3766 3767

Bit 7: BYTE This bit indicates the length unit for Length. Permissible values for BYTE and the resulting definition of the process data length in conjunction with Length are listed in Table B.6. Table B.6 Permitted combinations of BYTE and Length
BYTE 0 0 0 0 Length 0 1 ... 16 no process data 1 bit process data, structured in bits dito 16 bit process data, structured in bits Definition

Working Draft
BYTE 0 1 1 1 1 Length 17 to 31 0, 1 2 ... 31

208
Definition Reserved Reserved

61131-9/WD V0.5 IEC

3 octets process data, structured in octets dito 32 octets process data, structured in octets

3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3782 3783 3784 3785 3786 3787 3788 3789 3790 3791 3792 3793 3794 3795 3796 3797 3798 3799 3800 3801 B.1.8 ProcessDataOut

The structure of the ProcessDataOut parameter is the same as with ProcessDataIn, except with bit 6 ("SIO") reserved. B.1.9 VendorID (VID)

These octets contain a worldwide unique value per vendor. This value is assigned by the organization listed in Annex K. B.1.10 DeviceID (DID)

These octets contain the actual DeviceID. A value of "0" is not permitted. It can be overwritten (10.6.2). An accepted different DeviceID shall be volatile.
NOTE The communication parameters MinCycleTime, F-sequence Capability, Process Data In and Process Data Out can be changed to achieve compatibility to the requested DeviceID.

B.1.11

FunctionID (FID)

This parameter will be defined in a later version. B.1.12 SystemCommand

Only Devices without ISDU support shall use the parameter SystemCommand in the direct parameter page 1. The implementation of SystemCommand is optional. See Table B.8 for a detailed description of the SystemCommand functions.
NOTE The SystemCommand on the Direct Parameter page 1 does not provide a positive or negative response upon execution of a selected function

B.1.13

Device specific direct parameter page 2

The Device specific direct parameters are a set of parameters available to the Device specific technology. The implementation of Device specific direct parameters is optional.
NOTE The complete parameter list of the direct parameter page 2 is read or write accessible via index 1 (see B.1.1).

B.2
B.2.1

Predefined Device parameters

Overview

The many different technologies and designs of sensors and actuators require individual and easy access to complex parameters and commands beyond the capabilities of the direct parameter page 2. From a Master's point of view, these complex parameters and commands are called application data objects. So-called ISDU "containers" are the transfer means to exchange application data objects or short data objects. The index of the ISDU is used to address the data objects. The following Figure B.6 illustrates the general mapping of data objects for the ISDU transmission.

61131-9/WD V0.5 IEC

209

Working Draft

Parameter via ISDU

Reserved 0x5000 0xFFFF

Device parameters (individual or profile)

Profile specific Index 0x4000 0x4FFF

Extended Index 0x0100 0x3FFF

Preferred Index 0x40 0xFE

Predefined parameters

Profile specific parameter 0x30 0x3F Diagnosis 0x20 0x2F Identification 0x10 0x1F System 0x02 0x0F

3802 3803 3804 3805 3806 Figure B.6 Index space for ISDU data objects This clause contains definitions and requirements for the implementation of technology specific Device applications. General implementation rules for parameters and commands shall be considered as shown in Figure B.7:
1) 2) 3) 4) All parameters of an Index shall be readable and/or writeable as an entire data object via Subindex 0. The technology specific device application shall resolve inconsistencies of dependent parameter sets during reparameterization. The duration of an SPDU service request is limited (Table 91). A master application can abort SPDU services after this timeout. Application commands (for example teach-in, reset to factory settings, etc.) are treated like parameters. The initiated execution of an application command is confirmed with a positive service response Write.res(+). A negative service response Write.res(-) shall indicate that the execution of the application command failed. In both cases the timeout limit shall be considered (Table 91)

3807 3808 3809 3810 3811

Index (dec) 0x0000 (0)

Figure B.7 Implementation rules for parameters and commands Table B.7 defines the assignment of data objects (parameters and commands) to the Index range of ISDUs. All indices above 2 are ISDU related. Table B.7 Index assignment of data objects (Device parameter)
Object name Direct Parameter Page 1 Access R Length Data type RecordT M/O/ C M Remark Redirected to the page communication channel, see 10.7.4

Working Draft
Index (dec) 0x0001 (1) 0x0002 (2) 0x0003 (3) 0x00040x000B (4-11) 0x000C (12) 0x000D (13) 0x000E (14) 0x000F (15) 0x0010 (16) 0x0011 (17) 0x0012 (18) 0x0013 (19) 0x0014 (20) 0x0015 (21) 0x0016 (22) 0x0017 (23) 0x0018 (24) 0x00190x001F (25-31) 0x0020 (32) 0x00210x0023 (33-35) 0x0024 (36) 0x0025 (37) 0x00260x0027 (38-39) Object name Direct Parameter Page 2 SystemCommand Data Storage Index Reserved Access R/W Length

210
Data type RecordT M/O/ C M

61131-9/WD V0.5 IEC

Remark Redirected to the page communication channel, see 10.7.4 Command Code Definition (See B.2.2) Set of data objects for storage (See B.2.3) Reserved for exceptional operations

W R/W

1 octet variable

UIntegerT RecordT

M/O M

Device Access Locks Profile Characteristic PDInput Descriptor PDOutput Descriptor Vendor Name Vendor Text Product Name Product ID Product Text SerialNumber Hardware Revision Firmware Revision Application Specific Tag Reserved

R/W

2 octets

RecordT

Standardized Device locking functions (See B.2.4) See [12]

variable

RecordT

R R R R R R R R R R R/W

variable variable max. 64 octets max. 64 octets max. 64 octets max. 64 octets max. 64 octets max. 16 octets max. 64 octets max. 64 octets Min. 16, max. 32 octets

RecordT RecordT StringT StringT StringT StringT StringT StringT StringT StringT StringT

O O M O M O O O O O O

See [12] See [12] Informative (See B.2.6) Additional vendor information (See B.2.7) Detailed product or type name (See B.2.8) Product or type identification (See B.2.9 and [3] for details) Description of Device function or characteristic (See B.2.10) Vendor specific serial number (See B.2.11) Vendor specific format (See B.2.12) Vendor specific format (See B.2.13) Tag location or tag function defined by user (See B.2.14)

Error Count Reserved

2 octets

UIntegerT

Errors since power-on or reset (See B.2.15)

Device Status Detailed Device Status Reserved

R R

1 octet variable

UIntegerT RecordT

O O

Contains current status of the Device (See B.2.16) See B.2.17 and [12]

61131-9/WD V0.5 IEC

Index (dec) 0x0028 (40) 0x0029 (41) 0x0020x002F (42-47) 0x0030 (48) 0x00310x003F (49-63) 0x00400x00FE (64-254) 0x00FF (255) 0x01000x3FFF (25616383) 0x40000x4FFF (1638420479) 0x50000xFFFF (2048065535) Key Object name ProcessDataInput Access R Length PD length PD length

211
Data type Device specific Device specific M/O/ C O O Remark

Working Draft

Read last valid process data from PDin channel (See B.2.17) Read last valid process data from PDout channel (See B.2.19)

ProcessR DataOutput Reserved

Offset Time Reserved for profiles Preferred Index Reserved Extended Index

R/W

1 octet

RecordT

Synchronization of Device application timing to F-sequence timing (See B.2.20)

Device specific (8 bit)

Device specific (16 bit)

Profile specific Index Reserved

To be defined within a separate document [12]

M = mandatory; O = optional; C = conditional

3812 3813 3814 3815 3816 3817 3818 3819 3820 3821
Command (hex) 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 to 0x3F

B.2.2

SystemCommand

Devices with ISDU support shall use the ISDU Index 0x0002 to receive the SystemCommand. The commands shall be acknowledged. A positive acknowledge indicates the complete and correct finalization of the requested command. A negative acknowlegde indicates the command cannot be realized or ended up with an error. A SystemCommand shall be executed within less than 5 seconds to fulfil the ISDU timing requirements (Table 91). Implementation of the SystemCommand feature is mandatory for Masters and optional for Devices. The coding of SystemCommand is shown in Table B.8. Table B.8 Coding of SystemCommand (ISDU)
Command (dec) 0 1 2 3 4 5 6 7 to 63 Command name Reserved ParamUploadStart ParamUploadEnd ParamDownloadStart ParamDownloadEnd ParamDownloadStore ParamBreak Reserved O O O O O O Start parameter upload Stop parameter upload Start parameter download Stop parameter download Finalize parameterization and start data storage Cancel all Param commands M/O Definition

Working Draft
Command (hex) 0x40 to 0x7F 0x80 0x81 0x82 0x83 to 0x9F 0xA0 to 0xFF NOTE Key Command (dec) 64 to 127 128 129 130 131 to 159 160 to 255 Command name Reserved for profiles Device reset Application reset

212
M/O

61131-9/WD V0.5 IEC

Definition

O O O

Restore factory settings Reserved Vendor specific

See 10.3 M = mandatory; O = optional

3822 3823 3824 3825 3826 3827 3828

The implementation of the parameterization commands is optional. However, all of these commands 0x01 0x06 or none of them shall be implemented. See B.1.12 for SystemCommand options on the direct parameter page 1. B.2.3 Data Storage Index

The parameter Data Storage Index (0x0003) contains all the information to be used for the data storage handling. Table B.9 shows the Data Storage Index assignments. Table B.9 Data Storage Index assignments
Index 0x0003 Subindex 01 Access R/W Parameter Name DS_Command 0x00: 0x01: 0x02: 0x03: 0x04: 0x05: 0x06 to 0xFF: Coding Reserved DS_UploadStart DS_UploadEnd DS_DownloadStart DS_DownloadEnd DS_Break Reserved Data type UIntegerT (8 bit)

02

State_Property

Bit 0: Reserved Bit 1and 2: State of Data Storage 0b00: Inactive 0b01: Upload 0b10: Download 0b11: Data storage locked Bit 3 to 6: Reserved Bit 7: DS_UPLOAD_FLAG "1": DS_UPLOAD_REQ pending "0": no DS_UPLOAD_REQ

UIntegerT (8 bit)

03

Data_Storage_ Size

Number of octets for storing all the necessary information for the Device replacement (see 10.4.5). Maximum size is 2 048 octets. Parameter set revision indication: CRC signature or Revision Counter (10.4.8) List of parameter indices to be saved (Table B.10)

UIntegerT (32 bit)

04

Parameter_ Checksum Index_List

UIntegerT (32 bit) OctetStringT (variable)

05

3829 3830 3831

DS_Command This octet carries the Data Storage commands for the Device.

61131-9/WD V0.5 IEC 3832 3833 3834 3835 3836 3837 3838 3839 3840 3841 3842 3843 3844 3845 3846 3847 3848 3849 3850
Entry X1

213

Working Draft

State_Property This octet indicates the current status of the Data Storage mechanism. Bit 7 shall be stored in non-volatile memory. The Master checks this bit at start-up and performs a parameter upload if requested. Data_Storage_Size These four octets provide the requested memory size as number of octets for storing all the information required for the replacement of a Device including the structural information (Index, Subindex). Data type is UIntegerT (32 bit). The maximum size is 2 048 octets. See Table F.1. Parameter_Checksum This checksum is used to detect changes in the parameter set without reading all parameters. The value of the checksum is calculated according to the procedure in 10.4.8. The Device shall change the checksum whenever a parameter out of the parameter set has been altered. Different parameter sets shall hold different checksums. It is recommended that the Device stores this parameter locally in non-volatile memory. Index_List Table B.10 shows the structure of the Index_List. Each Index_List can carry up to 70 entries (Table 91). Table B.10 Structure of Index_List
Address Index Subindex X2 Index Subindex .. Xn Index Subindex Xn+1 Index Definition Index of first parameter to be saved Subindex of first parameter to be saved Index of next parameter to be saved Subindex of next parameter to be saved . Index of last parameter to be saved Subindex of last parameter to be saved Termination_Marker 0x0000: End of Index_List >0x0000: Next Index containing an Index_List Data type Unsigned16 Unsigned8 Unsigned16 Unsigned8 .. Unsigned16 Unsigned8 Unsigned16

3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861 3862 3863 3864 3865

Large sets of parameters can be handled via concatenated Index_Lists. The last two octets of the Index_List shall carry the Termination Marker. A value 0 indicates the end of the Index List. In case of concatenation the Termination Marker is set to the next Index containing an Index List. The structure of the following Index List is the same as described in Table B.10. Thus, the concatenation of lists ends if a Termination Marker with the value 0 is found. B.2.4 Device Access Locks

The parameter Device Access Locks allows control of the Device behaviour. Standardized Device functions can independently be configured via defined flags in this parameter. The Device Access Locks configuration can be changed by overwriting the parameter. The actual configuration setting is available per read access to this parameter. The data type is RecordT of BooleanT. Access is only permitted via Subindex 0. This parameter is optional. If implemented it shall be non-volatile. The following Device access lock categories are defined. Parameter write access (optional) Data storage (mandatory if the Device supports data storage)

Working Draft 3866 3867 3868 3869

Bit 0 1 2 3 4 - 15

214

61131-9/WD V0.5 IEC

Local parameterization (optional) Local user interface operation (optional)

The following Table B.11 shows the Device locking possibilities. Table B.11 Device locking possibilities
Category Parameter (write) access (optional) Data storage (mandatory if the Device supports data storage) Local parameterization (optional) Local user interface (optional) Reserved Definition 0: unlocked (default) 1: locked 0: unlocked (default) 1: locked (see NOTE) 0: unlocked (default) 1: locked 0: unlocked (default) 1: locked

NOTE The Master reads the parameter State_Property/State of Data Storage (Table B.9 prior to any actions

3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888 3889 3890 3891 3892 3893 3894

Parameter (write) access: If this bit is set, write access to all Device parameters over the SDCI communication interface is inhibited for all read/write parameters of the Device except the parameter Device Access Locks. Read access is not affected. The Device shall respond with the negative service response - access denied to a write access, if the parameter access is locked. The Data Storage mechanism overrules the parameter (write) access lock mechanism temporarily between DS_DownloadStart and DS_DownloadEnd or DS_Break. Data storage: If this bit is set, the data storage mechanism is inhibited. In this case, the Device shall respond to a write access (within the Data Storage Index) with a negative service response access denied (see B.2.3). Read access to Data Storage Index is not affected. This setting is also indicated in the State Property within Data Storage Index Local parameterization: If this bit is set, the parameterization via local control elements on the Device is inhibited. Local user interface: If this bit is set, operation of the human machine interface on the Device is disabled. B.2.5 Profile Characteristic

The profile parameter Profile Characteristic is defined in a separate document [12]. Indices 0x000E to 0x000F are reserved for further Device profiles. B.2.6 Vendor Name

The parameter Vendor Name contains only one of the names of the vendors listed for the assigned VendorID. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64. This parameter is mandatory.
NOTE These predefined parameters are always coded as UTF-8 (see E.2.6)

61131-9/WD V0.5 IEC 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3908 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3919 3920 3921 3922 3923 3924 3925 3926 3927 3928 3929 3930 3931 3932 3933 3934 3935 B.2.7 Vendor Text

215

Working Draft

The parameter Vendor Text contains additional information about the vendor. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64. This parameter is optional. B.2.8 Product Name

The parameter Product Name shall contain the complete product name and shall match the corresponding entry in the IODD Device variant list. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64. This parameter is mandatory. B.2.9 Product ID

The parameter Product ID shall contain the vendor specific product or type identification of the Device. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64 (see [3] for details). This parameter is optional. B.2.10 Product Text

The parameter Product Text shall contain additional product information for the Device, such as product category (for example Photoelectric Background Suppression, Ultrasonic Distance Sensor, Pressure Sensor, etc.). The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64. This parameter is optional. B.2.11 SerialNumber

The parameter SerialNumber shall contain a unique vendor specific code for each individual Device. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 16. This parameter is optional. B.2.12 Hardware Revision

The parameter Hardware Revision shall contain a vendor specific coding for the hardware revision of the Device. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64. This parameter is optional. B.2.13 Firmware Revision

The parameter Firmware Revision shall contain a vendor specific coding for the firmware revision of the Device. The parameter is a read-only data object. The data type is StringT with a maximum fixedLength of 64. This parameter is optional. B.2.14 Application Specific Tag

The parameter Application Specific Tag shall be provided as read/write data object for the user application. It can serve as a "tag function" (role of the Device) or a "tag location" (location of the Device). The data type is StringT with a minimum fixedLength of 16 and a maximum fixedLength of 32. As default it is recommended to fill this parameter with "***". This parameter is optional.
NOTE In process automation usually this length is 32 octets.

B.2.15

Error Count

The parameter Error Count provides information on errors occurred in the Device application since power-on or reset. Usage of this parameter is vendor or Device specific. The data type is UIntegerT with a bitLength of 16. The parameter is a read-only data object. This parameter is optional.

Working Draft 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948
Value 0 1

216

61131-9/WD V0.5 IEC

B.2.16 B.2.16.1

Device Status Overview

The parameter Device Status shall provide information about the Device condition (diagnosis) by the Device's technology. The data type is UIntegerT with a bitLength of 8. The parameter is a read-only data object. This parameter is optional. The following Device conditions in Table B.12 are defined. They shall be generated by the Device applications. The parameter Device Status can be screened by any PLC program or tools such as Asset Management (11). Table B.12 shows the different Device Status information together with the recommended colors and symbols in [16]. The criteria for these indications are defined in sections B.2.16.2 through B.2.16.5. Investigations are in progress to find relevant standards in ISO/IEC if any Table B.12 Device status parameter
Definition Device is OK Maintenance-Required B.2.16.2 Color indication (process monitoring) Green Blue Symbol (process monitoring) None

Out-of-Specification B.2.16.3

Yellow

?
Orange

Functional-Check B.2.16.4

Failure B.2.16.5

Red

5 - 255

Reserved

3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 B.2.16.2 Maintenance-required

Although the process data are valid, the Device is close to loose its ability of correct functioning due to operational conditions, for example optical lenses dusty, build-up of deposits, lubricant level low, etc. B.2.16.3 Out-of-Specification

Although the process data are valid, the Device is operating outside its specified measuring range or environmental conditions (power supply, auxiliary energy, temperature, pneumatic pressure, magnetic interference, vibrations, acceleration, interfering light, bubble formation in liquids, etc.). B.2.16.4 Functional-Check

Process Data temporarily invalid due to intended manipulations on the Device (calibrations, teach-in, position adjustments, simulation, etc.).

61131-9/WD V0.5 IEC 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976
Subindex 1

217

Working Draft

B.2.16.5

Failure

Process Data invalid due to malfunction in the Device or its peripherals. The Device is unable to perform its intended function. B.2.17 Detailed Device Status

The parameter Detailed Device Status shall provide information about currently pending Events in the Device. Events of TYPE "Error" or "Warning" and MODE "Event appears" (A.6.4) shall be entered into the list of Detailed Device Status with EventQualifier and EventCode. Upon occurrence of an Event with MODE "Event disappears", the corresponding entry in Detailed Device Status shall be set to EventQualifier "0x00" and EventCode "0x0000". This way this parameter always provides the current diagnosis status of the Device. The parameter is a read-only data object. The data type is ArrayT with a maximum number of 64 array elements (Event entries). The number of array elements of this parameter is Device specific. Upon power-off or reset of the Device the contents of all array elements is set to initial settings - EventQualifier "0x00", EventCode "0x0000". This parameter is optional. Table B.13 Detailed Device Status (Index 0x0025)
Object name Error_Warning_1 R/W R Mandatory /optional M Data Type 3 octets Comment All octets 0x00: no Error/ Warning Octet 1: EventQualifier Octet 2,3: EventCode dito dito dito

2 3 4 n

Error_Warning_2 Error_Warning_3 Error_Warning_4

R R R

M M M

3 octets 3 octets 3 octets

Error_Warning_n

3 octets

dito

3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993 3994 3995 Table B.13 shows the structure of the parameter Detailed Device Status [12].
NOTE The vendor can choose the implementation of a static list, i.e. one fix array position for each Event with a specific EventCode, or a dynamic list, i.e. each Event entry is stored into the next free array position.

B.2.18

ProcessDataInput

The parameter ProcessDataInput shall provide the last valid process input data from the Device application. The data type and structure is identical to the Process Data In transferred in the process communication channel. The parameter is a read-only data object. This parameter is optional. B.2.19 ProcessDataOutput

The parameter ProcessDataOutput shall provide the last valid process output data written to the Device application. The data type and structure is identical to the Process Data Out transferred in the process communication channel. The parameter is a read-only data object. This parameter is optional. B.2.20 Offset Time

The parameter Offset Time allows a Device application to synchronize on F-sequence cycles of the data link layer via adjustable offset times. The data type is RecordT. Access is only possible via Subindex 0. The parameter is a read/write data object. This parameter is optional.

Working Draft 3996

218

61131-9/WD V0.5 IEC

The structure of the parameter Offset Time is illustrated in the following Figure B.8:
Time base Multiplier

3997 3998 3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 Bits 0 to 5: Multiplier These bits contain a 6-bit factor for the calculation of the Offset Time. Permissible values for the multiplier are 0 to 63. Bits 6 to 7: Time Base These bits contain the time base for the calculation of the Offset Time. The permissible combinations for Time Base and Multiplier are listed in the following Table B.14 along with the resulting values for Offset Time. Setting both Multiplier and Time Base to zero deactivates synchronization with the help of an Offset Time. The value of Offset Time shall not exceed the MasterCycleTime (see B.1.3) Table B.14 Time base coding and values of Offset Time
Code (binary) 00 01 10 11 Time Base 0,01 ms 0,04 ms 0,64 ms 2,56 ms Calculation Multiplier * Time Base 0,64 ms + Multiplier * Time Base 3,20 ms + Multiplier * Time Base 44,16 ms + Multiplier * Time Base Offset Time 0,01 ms to 0,63 ms 0,64 ms to 3,16 ms 3,20 ms to 43,52 ms 44,16 ms to 126,08 ms

Figure B.8 Structure of the Offset Time

4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 B.2.21 Profile Parameter (reserved)

Indices 0x0031 to 0x003F are reserved for Device profiles. These parameters will be specified within a separate document [12]. B.2.22 Preferred Index

Preferred Indices (0x0040 to 0x00FE) can be used for vendor specific Device functions. This range of indices is considered preferred due to lower protocol overhead within the ISDU and thus higher data throughput for small data objects as compared to the Extended Index (see B.2.23). B.2.23 Extended Index

Extended Indices (0x0100 to 0x3FFF) can be used for vendor specific Device functions. B.2.24 Profile specific Index (reserved)

Indices 0x4000 to 0x4FFF are reserved for Device profiles. These parameters will be specified within a separate document [12].

61131-9/WD V0.5 IEC 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039
Incident Device application error no details Index not available Subindex not available Service temporarily not available Service temporarily not available - local control Service temporarily not available Device control Access denied Parameter value out of range Parameter value above limit Parameter value below limit Parameter length overrun Parameter length underrun Error Code 0x80 0x80 0x80 0x80

219

Working Draft

Annex C (normative) ErrorTypes (ISDU errors)

C.1 General

An ErrorType is used within negative service confirmations of ISDU s (A.5.2 and Table A.13). It indicates the cause of a negative confirmation of a Read or Write service. The origin of the error may be located in the Master (local) or in the Device (remote). The ErrorType consists of two octets, the main error cause and more specific information: ErrorCode (high order octet) AdditionalCode (low order octet)

The ErrorType represents information about the incident, the origin and the instance. The permissible ErrorTypes and the criteria for their deployment are listed in C.2 and C.3. All other ErrorType values are reserved and shall not be used.

C.2
C.2.1

Application related ErrorTypes

Overview

The permissible ErrorTypes resulting from the Device application are listed in Table C.1. Table C.1 ErrorTypes
Additional Code 0x00 0x11 0x12 0x20 APP_DEV IDX_NOTAVAIL SUBIDX_NOTAVAIL SERV_NOTAVAIL Name Definition See C.2.2 See C.2.3 See C.2.4 See C.2.5

0x80

0x21

SERV_NOTAVAIL_LOCCTRL

See C.2.6

0x80

0x22

SERV_NOTAVAIL_DEVCTRL

See C.2.7

0x80 0x80 0x80 0x80 0x80 0x80

0x23 0x30 0x31 0x32 0x33 0x34

IDX_NOT_WRITABLE PAR_VALOUTOFRNG PAR_VALGTLIM PAR_VALLTLIM VAL_LENOVRRUN VAL_LENUNDRUN

See C.2.8 See C.2.9 See C.2.10 See C.2.11 See C.2.12 See C.2.13

Working Draft
Incident Function not available Function temporarily unavailable Invalid parameter set Inconsistent parameter set Application not ready Vendor specific Vendor specific Error Code 0x80 0x80 Additional Code 0x35 0x36

220
Name FUNC_NOTAVAIL FUNC_UNAVAILTEMP

61131-9/WD V0.5 IEC

Definition See C.2.14 See C.2.15

0x80 0x80

0x40 0x41

PAR_SETINVALID PAR_SETINCONSIST

See C.2.16 See C.2.17

0x80 0x81 0x81

0x82 0x00 0x01 to 0xFF

APP_DEVNOTRDY UNSPECIFIC VENDOR_SPECIFIC

See C.2.18 See C.2.19 See C.2.19

4040 4041 4042 4043 4044 4045 4046 4047 4048 4049 4050 4051 4052 4053 4054 4055 4056 4057 4058 4059 4060 4061 4062 4063 4064 C.2.2 Device application error no details

This ErrorType shall be used if the requested service has been refused by the Device application and no detailed information of the incident is available. C.2.3 Index not available

This ErrorType shall be used whenever a read or write access occurs to a not existing Index. C.2.4 Subindex not available

This ErrorType shall be used whenever a read or write access occurs to a not existing Subindex. C.2.5 Service temporarily not available

This ErrorType shall be used if a parameter is not accessible for a read or write service due to the current state of the Device application. C.2.6 Service temporarily not available local control

This ErrorType shall be used if a parameter is not accessible for a read or write service due to an ongoing local operation at the Device (for example operation or parameterization via an on-board Device control panel). C.2.7 Service temporarily not available device control

This ErrorType shall be used if a read or write service is not accessible due to a remote triggered state of the device application (for example parameterization during a remote triggered teach-in operation or calibration). C.2.8 Access denied

This ErrorType shall be used if a write service tries to access a read-only parameter. C.2.9 Parameter value out of range

This ErrorType shall be used for a write service to a parameter outside its permitted range of values.

61131-9/WD V0.5 IEC 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075 4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 C.2.10 Parameter value above limit

221

Working Draft

This ErrorType shall be used for a write service to a parameter above its specified value range. C.2.11 Parameter value below limit

This ErrorType shall be used for a write service to a parameter below its specified value range. C.2.12 Parameter length overrun

This ErrorType shall be used for a write service to a parameter above its specified length. This ErrorType shall also be used, if a data object is too large to be processed by the Device application (for example ISDU buffer restriction). C.2.13 Parameter length underrun

This ErrorType shall be used for a write service to a parameter below its predefined length (for example write access of an Unsigned16 value to an Unsigned32 parameter). C.2.14 Function not available

This ErrorType shall be used for a write service with a command value not supported by the Device application (for example a SystemCommand with a value not implemented). C.2.15 Function temporarily unavailable

This ErrorType shall be used for a write service with a command value calling a Device function not available due to the current state of the Device application (for example a SystemCommand). C.2.16 Invalid parameter set

This ErrorType shall be used if values via single parameter transfer collide with other actual parameter settings (for example overlapping set points for a binary data setting; see 10.3.4). C.2.17 Inconsistent parameter set

This ErrorType shall be used at the termination of a block parameter transfer with ParamDownloadEnd or ParamDownload Store if the plausibility check shows inconsistencies (see 10.3.5 and B.2.2). C.2.18 Application not ready

This ErrorType shall be used if a read or write service is refused due to a temporarily unavailable application (for example peripheral controllers during startup). C.2.19 Vendor specific

This ErrorType will be propagated directly to higher level processing elements as an error (no warning) by the Master.

Working Draft 4099 4100 4101 4102 4103

Incident Communication error Timeout Device event ISDU error (DL, Error, single shot, 0x5600) Device event ISDU illegal service primitive (AL, Error, single shot, 0x5800) Master ISDU checksum error

222

61131-9/WD V0.5 IEC

C.3
C.3.1

Derived ErrorTypes
Overview

Derived ErrorTypes are generated in the Master application and are caused by internal incidents or those received from the Device. Table C.2 lists the defined Derived ErrorTypes. Table C.2 Derived ErrorTypes
Error Code 0x10 0x11 0x11 0x11 Additional Code 0x00 0x00 0x00 0x00 Name COM_ERR SERV_TIMEOUT SERV_TIMEOUT SERV_TIMEOUT Definition See C.3.2 See C.3.3 See C.3.4 See C.3.5

0x56

0x00

M_ ISDU_CHECKSUM

See C.3.6

Master ISDU illegal service primitive

0x57

0x00

M_ ISDU_ILLEGAL

See C.3.7

Device event ISDU buffer overflow (DL, Error, single shot, 0x5200)

0x80

0x33

VAL_LENOVRRUN

See C.3.8 and C.2.12 (see NOTE)

NOTE Events from legacy V1.0 Devices [13] are redirected in compatibility mode to this derived ErrorType

4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 C.3.2 Communication error

The Master generates a negative service response with this ErrorType if a communication error occurred during a read or write service, for example the SDCI connection is interrupted. C.3.3 Timeout

The Master generates a negative service response with this ErrorType, if a Read or Write service is pending longer than the defined service timeout in the Master. C.3.4 Device event ISDU error

If the Master received an event with the EventQualifier (A.6.4: DL, Error, Event single shot) and the EventCode 0x5600, a negative service response indicating a service timeout is generated and returned to the requester (see C.3.3). C.3.5 Device event ISDU illegal service primitive

If the Master received an event with the EventQualifier (A.6.4: AL, Error, Event single shot) and the EventCode 0x5800, a negative service response indicating a service timeout is generated and returned to the requester (see C.3.3). C.3.6 Master ISDU checksum error

The Master generates a negative service response with this ErrorType, if its data link layer detects an ISDU checksum error.

61131-9/WD V0.5 IEC 4122 4123 4124 4125 4126 4127 4128 C.3.7

223

Working Draft

Master ISDU illegal service primitive

The Master generates a negative service response with this ErrorType, if its data link layer detects an ISDU illegal service primitive. C.3.8 Device event ISDU buffer overflow

If the Master received an event with the EventQualifier (A.6.4: DL, Error, Event single shot) and the EventCode 0x5200, a negative service response indicating a parameter length overrun is generated and returned to the requester (see C.2.12).

Working Draft 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142
EventCodes

224

61131-9/WD V0.5 IEC

Annex D (normative) EventCodes (diagnosis information)

D.1 General

The concept of events is described in 7.3.8.1 and the general structure and encoding of events in A.6. Whenever the Status Code indicates an event in case of a Device or a Master incident, the associated EventCode shall be provided as diagnosis information. As specified in A.6, the event entry contains an EventCode in addition to the Event Qualifier. The EventCode identifies an actual incident. Permissible values for EventCode are listed in Table D.1; all other EventCode values are reserved and shall not be used.

D.2

EventCodes for Devices

Table D.1 lists the defined EventCode identifiers and their definitions. The EventCodes are created by the technology specific Device application (instance = APP). Table D.1 EventCodes
Definition Device Status Value (NOTE 1) 0 4 TYPE (NOTE 2)

0x0000 0x1000 0x1001 to 0x17FF 0x1800 to 0x18FF 0x1900 to 0x3FFF 0x4000 0x4001 to 0x420F 0x4210 0x4211 to 0x421F 0x4220 0x4221 to 0x4FFF 0x5000 0x5001 to 0x500F 0x5010 0x5011 0x5012 0x5013 to 0x50FF 0x5100 0x5101 0x5102 to 0x510F 0x5110 0x5111 0x5112 0x5113 to 0x5FFF 0x6000

No malfunction General malfunction unknown error Reserved Manufacturer/ vendor specific Reserved Temperature fault Overload Reserved Device temperature over-run Clear source of heat Reserved Device temperature under-run Insulate Device Reserved Device hardware fault Device exchange Reserved Component malfunction Repair or exchange Non volatile memory loss Check batteries Batteries low Exchange batteries Reserved General power supply fault Check availability Fuse blown/open Exchange fuse Reserved Primary supply voltage over-run Check tolerance Primary supply voltage under-run Check tolerance Secondary supply voltage fault (Port Class B) Check tolerance Reserved Device software fault Check firmware revision

Notification Error

Error

Warning

Warning

Error

4 4 2

Error Error Warning

4 4

Error Error

2 2 2

Warning Warning Warning

Error

61131-9/WD V0.5 IEC

0x6001 to 0x631F 0x6320 0x6321 0x6322 to 0x634F 0x6350 0x6351 to 0x76FF 0x7700 0x7701 to 0x770F 0x7710 0x7711 0x7712 to 0x8BFF 0x8C00 0x8C01 0x8C02 to 0x8C0F 0x8C10 0x8C11 to 0x8C1F 0x8C20 0x8C21 to 0x8C2F 0x8C30 0x8C31 to 0x8C3F 0x8C40 0x8C41 0x8C42 0x8C43 to 0x8C9F 0x8CA0 to 0x8DFF 0x8E00 to 0xAFFF 0xB000 to 0xBFFF 0xC000 to 0xFEFF 0xFF00 to 0xFFFF NOTE 1 NOTE 2 Reserved

225

Working Draft

Parameter error Check data sheet and values Parameter missing Check data sheet Reserved Parameter changed Check configuration Reserved Wire break of a subordinate device Check installation Wire break of subordinate device 1 device 15 Check installation Short circuit Check installation Ground fault Check installation Reserved Technology specific application fault Reset Device Simulation active Check operational mode Reserved Process variable range over-run Process Data uncertain Reserved Measurement range over-run Check application Reserved Process variable range under-run Process Data uncertain Reserved Maintenance required Cleaning Maintenance required Refill Maintenance required Exchange wear and tear parts Reserved Manufacturer/ vendor specific Reserved Reserved for profiles [12] Reserved SDCI specific EventCodes (see Table D.2)

4 4

Error Error

Error

4 4 4 4

Error Error Error Error

4 3

Error Warning

Warning

Error

Warning

1 1 1

Notification Notification Notification

See B.2.16 See Table A.19

4143 4144 4145 4146 4147

Incident Origin

Table D.2 presents an overview of the encoding of typical SDCI events related to Process Data, System Management, Device or Master application and others. This overview does not claim to be complete. Table D.2 Exemplary SDCI specific EventCodes
Instance Type Mode With details Process Data Address increment error Remote DL ERROR Singleshot PD_INCR 0xFFE1 PD stop Missing PD address Name Event Code Action Remark

Working Draft
Incident Access outside PD length Incomplete PD length Origin Remote Instance DL Type ERROR

226
Mode Singleshot Name PD_LEN

61131-9/WD V0.5 IEC

Event Code 0xFFE2 Action PD stop Remark Written or read PD length too long Written or read PD length too short

Remote

DL

ERROR

Singleshot

PD_SHORT

0xFFE3

PD stop

Read at input length "0"

Remote

DL DL

ERROR ERROR

Singleshot Singleshot

NO_PDIN NO_PDOUT

0xFFE4 0xFFE5

PD stop PD stop

Write at output Remote length "0" System Management Mode indication Device communication lost Data Storage identification mismatch Local Local

DL APP

NOTIFICATION NOTIFICATION NOTIFICATION NOTIFICATION NOTIFICATION

Singleshot Singleshot Singleshot Singleshot Singleshot

NEW_SLAVE DEV_COM_ LOST DS_IDENT_ MISMATCH DS_BUFFER _OVERFLOW DS_ACCESS _DENIED

0xFF21 0xFF22

PD stop -

See 11 See 11

Local

APP

0xFF23

See 11

Data Storage Local buffer overflow Data Storage parameter access denied Unspecified Incorrect event signalling Local Local

APP APP

0xFF24 0xFF25

See 11 See 11

DL

ERROR

Singleshot

EVENT

0xFF31

Event.ind

See 11

Device specific application Data Storage upload request Reserved Remote APP NOTIFICATION NOTIFICATION Singleshot Singleshot DS_UPLOAD _REQ 0xFF91 Event.ind

Remote

APP

0xFF98

Event.ind

Shall not be used

4148

61131-9/WD V0.5 IEC 4149 4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162 4163 4164 4165 4166 4167 4168 4169
Data type name BooleanT

227

Working Draft

Annex E (normative) Data types

E.1 General

This annex provides a brief overview of the available basic and composite data types to be used. More detailed definitions are available in [3]. Examples demonstrate the structures and the transmission aspects of data types for singular use or in a packed manner.

E.2
E.2.1

Basic data types

General

The coding of basic data types is shown only for singular use, which is characterized by Process data consisting of one basic data type Parameter consisting of one basic data type Subindex (>0) access on individual data items of parameters of composite data types (arrays, records) BooleanT

E.2.2

A BooleanT is representing a data type that can have only two different values i.e. TRUE and FALSE. The data type is defined in Table E.1. For singular use the coding is shown in Table E.2. A sender shall always use 0xFF for 'TRUE' or 0x00 for 'FALSE'. A receiver can interpret the range from 0x01 through 0xFF for 'TRUE' and shall interpret 0x00 for 'FALSE' to simplify implementations. The packed form is demonstrated in Table E.20 and Figure E.10. Table E.1 BooleanT
Value range TRUE / FALSE Resolution Length 1 bit or 1 octet

4170 4171
Bit TRUE FALSE 1 0 7 1 0 6 1 0

Table E.2 BooleanT coding

5 1 0 4 1 0 3 1 0 2 1 0 1 1 0 0 0xFF 0x00 Values

4172 4173 4174 4175 4176 4177 E.2.3 UIntegerT

A UIntegerT is representing an unsigned number depicted by 2 up to 64 bits ("enumerated"). The number is accommodated and right-aligned within the following permitted octet containers: 1, 2, 4, or 8. High order padding bits are filled with "0". Coding examples are shown in Figure E.1.

Working Draft
Value = 13 4 bit 1 octet 0 0 0 0 0 0 0 0 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1

228

61131-9/WD V0.5 IEC

Padding bits = 0

Value = 93786 17 bit 4 octets 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1 1

0 0

1 1

1 0 1 0

1 1

1 1

1 1

0 0

0 0

1 1

0 0

1 1

1 1

0 0

1 1

0 0

1 1

0 0

1 1

1 0 1 0

1 1

1 1

1 1

0 0

0 0

1 1

0 0

1 1

1 1

0 0

1 1

0 0

4178 4179 4180 4181 4182

Padding bits = 0

Figure E.1 Coding examples of UIntegerT The data type UIntegerT is defined in Table E.3 for singular use.

Table E.3 UIntegerT

Data type name UIntegerT Value range 0 2 bitlength - 1 1 Resolution 1 2 4 8 Length octet, or octets, or octets, or octets

NOTE 1 NOTE 2

High order padding bits are filled with "0" Most significant octet (MSO) sent first

4183 4184 4185 4186 4187 4188 4189 4190

Data type name IntegerT

E.2.4

IntegerT

An IntegerT is representing a signed number depicted by 2 up to 64 bits. The number is accommodated within the following permitted octet containers: 1, 2, 4, or 8 and right-aligned and extended correctly signed to the chosen number of bits. The data type is defined in Table E.4 for singular use. SN represents the sign with "0" for all positive numbers and zero, and "1" for all negative numbers. Padding bits are filled with the content of the sign bit (SN). Table E.4 IntegerT
Value range -2 bitlength -1 2 bitlength -1 - 1 1 Resolution 1 2 4 8 Length octet, or octets, or octets, or octets

NOTE 1 NOTE 2

High order padding bits are filled with the value of the sign bit (SN) Most significant octet (MSO) sent first (lowest respective octet number in Table E.5)

4191 4192 4193 The 4 coding possibilities in containers are shown in Table E.5 through Table E.8.

61131-9/WD V0.5 IEC 4194

Bit Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 7 SN 2 55 2 47 2 39 2 31 2 23 2 15 27

229 Table E.5 IntegerT coding (8 octets)

6 2 62 2 54 2 46 2 38 2 30 2 22 2 14 26 5 2 61 2 53 2 45 2 37 2 29 2 21 2 13 25 4 2 60 2 52 2 44 2 36 2 28 2 20 2 12 24 3 2 59 2 51 2 43 2 35 2 27 2 19 2 11 23 2 2 58 2 50 2 42 2 34 2 26 2 18 2 10 22 1 2 57 2 49 2 41 2 33 2 25 2 17 29 21 0 2 56 2 48 2 40 2 32 2 24 2 16 28 20 Container 8 octets

Working Draft

4195 4196
Bit Octet 1 Octet 2 Octet 3 Octet 4 7 SN 2 23 2 15 27

Table E.6 IntegerT coding (4 octets)

6 2 30 2 22 2 14 26 5 2 29 2 21 2 13 25 4 2 28 2 20 2 12 24 3 2 27 2 19 2 11 23 2 2 26 2 18 2 10 22 1 2 25 2 17 29 21 0 2 24 2 16 28 20 Container 4 octets

4197 4198
Bit Octet 1 Octet 2 7 SN 27

Table E.7 IntegerT coding (2 octets)

6 2 14 26 5 2 13 25 4 2 12 24 3 2 11 23 2 2 10 22 1 29 21 0 28 20 Container 2 octets

4199 4200
Bit Octet 1 7 SN

Table E.8 IntegerT coding (1 octet)

6 26 5 25 4 24 3 23 2 22 1 21 0 20 Container 1 octet

4201 4202 Coding examples within containers are shown in Figure E.2

Working Draft
SN Value = -4 1 1 1 1 0 0 0 0

230

61131-9/WD V0.5 IEC

SN

SN = 0: positive numbers and zero SN = 1: negative numbers (Two's complement)

Value = +4

0 0

1 1

0 0

0 0

1 1

1 1

1 1

1 1

1 1

1 1

0 0

0 0

0 0

0 0

0 0

0 0

0 0

1 1

0 0

0 0

Padding bits = 1 (SN) SN Value = -28250 SN 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 1 1 17 bit 4 octets 1 1 1 1 0 0 0 0 1 1 0 0 0 0 0 0 1 1

Padding bits = 0 (SN)

1 1

0 0

1 1

0 0

0 0

1 1

1 1

0 0

1 1

0 0

1 1

0 0

0 0

1 1

1 1

0 0

4203 4204 4205 4206 4207 4208 4209 4210 E.2.5

Padding bits = 1 (SN)

Figure E.2 Coding examples of IntegerT

Float32T

A Float32T is representing a number defined by [10] as single precision (32 bit). Table E.9 shows the definition and Table E.10 the coding. SN represents the sign with "0" for all positive numbers and zero, and "1" for all negative numbers. Table E.9 Float32T
Data type name Float32T Value range Refer to [10] Resolution Refer to [10] Length 4 octets

4211 4212
Bits Octet 1

Table E.10 Coding of Float32T

7 SN 20 Octet 2 (E) 20 Octet 3 2 -8 Octet 4 2 -16 2 -17 2 -18 2 -9 2 -10 2 -1 2 -2 2 -3 27 26 25 6 5 4 3 Exponent (E) 24 23 22 21 2 1 0

Fraction (F) 2 -4 2 -5 2 -6 2 -7

Fraction (F) 2 -11 2 -12 2 -13 2 -14 2 -15

Fraction (F) 2 -19 2 -20 2 -21 2 -22 2 -23

4213 4214 4215 4216 4217 In order to realize negative exponent values a special exponent encoding mechanism is set in place as follows: The Float32T exponent (E) is encoded using an offset binary representation, with the zero offset being 127; also known as exponent bias in [10].

61131-9/WD V0.5 IEC 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229
Data type name StringT Encoding US-ASCII UTF-8 [11] [7]

231

Working Draft

E min = 0x01 - 0x7F = -126 E max = 0xFE - 0x7F = 127 Exponent bias = 0x7F = 127 Thus, as defined by the offset binary representation, in order to get the true exponent the offset of 127 shall be subtracted from the stored exponent.

E.2.6

StringT

A StringT is representing an ordered sequence of symbols (characters) with a variable or fixed length of octets (maximum of 232 octets) coded in US-ASCII (7 bit) or UTF-8 [7]. UTF-8 uses one octet for all ASCII characters and up to 4 octets for other characters. 0x00 is not permitted as a character. Table E.11 shows the definition. Table E.11 StringT
Standards Length Any length of character string with a maximum of 232 octets. The length shall be defined within a Device's IODD via the attribute 'fixedLength'.

4230 4231 4232 4233 4234 4235 4236 An instance of StringT can be shorter than defined by the IODD attribute 'fixedLength'. 0x00 shall be used for the padding of unused octets. Character strings can be transmitted in their actual length in case of singular access (Figure E.3). Optimization for transmission is possible by omitting the padding octets if the IODD attribute 'fixedLengthRestriction' is not set. The receiver can deduce the original length from the length of the ISDU or by searching the first NULL (0x00) character (See A.5.2 and A.5.3).
Transmission 0 0x48 0x48 1 0x45 0x45 2 0x4C 0x4C 3 0x4C 0x4C 4 0x4F 0x4F 5 0x00 0x00 6 0x00 0x00 Octet number Sender: 'fixedLength' =7 Padding of unused octets = 0x00

H 0x48 0x48

E 0x45 0x45

L 0x4C 0x4C

L 0x4C 0x4C

O 0x4F 0x4F Transmission options: StringT can be transmitted in condensed form or unmodified.

4237 4238 4239 4240 4241 4242 4243 E.2.7

0x48 0x48

0x45 0x45

0x4C 0x4C

0x4C 0x4C

0x4F 0x4F

0x00 0x00

0x00 0x00

Receiver: 'fixedLength' =7 Padding of unused octets = 0x00

Figure E.3 Singular access of StringT

OctetStringT

An OctetStringT is representing an ordered sequence of octets with a fixed length (maximum of 232 octets). Table E.12 shows the definition and Figure E.4 a coding example for a fixed length of 7.

Working Draft 4244

Data type name OctetStringT NOTE

232 Table E.12 OctetStringT

Value range 0x00 0xFF per octet Standards

61131-9/WD V0.5 IEC

Length Fixed length with a maximum of 232 octets

The length is defined within a Device's IODD via the attribute 'fixedLength'.

4245
0 1 0x0A 0x0A 2 0x23 0x23 3 0xAA 0xAA 4 0xBB 0xBB 5 0xA1 0xA1 6 0xD0 0xD0 Octet number

4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 E.2.8

0x1F 0x1F

Figure E.4 Coding example of OctetStringT

TimeT

A TimeT corresponds to the data type NetworkTime in IEC 61158-6:2003. It is based on the RFC 1305 standard [8] and composed of two unsigned values that express the network time related to a particular date. Its semantic has changed from RFC 1305 in IEC 61158-6:2003 [9] according to Figure E.5. Table E.13 shows the definition and Table E.14 the coding of TimeT. The first element is a 32-bit unsigned integer data type that provides the network time in seconds since 1900-01-01 0.00,00(UTC) or since 2036-02-07 6.28,16(UTC) for time values less than 0x9DFF4400, which represents the 1984-01-01 0:00,00(UTC). The second element is a 32-bit unsigned integer data type that provides the fractional portion of seconds in 1/2 32 s. Rollovers after 136 years are not automatically detectable and are to be maintained by the application.

New definition in IEC 61158-6:2003 RFC 1305 Standard 1900-01-01 1984-01-01 0x9DFF4400 s 2036-02-07 0xFFFFFFFF s Time

4260 4261 4262 4263

0x00000000 s

Figure E.5 New definition of NetworkTime in IEC 61158-6:2003

Table E.13 TimeT

Data type name TimeT Value range Octet 1 to 4 (see Table E.14): 0 i (2 32 -1) Octet 5 to 8 (see Table E.14): 0 i (2 32 -1) NOTE Resolution s (Seconds) (1/2 32 ) s Length 8 Octets (32 bit unsigned integer + 32 bit unsigned integer)

32 bit unsigned integer are normal computer science data types

61131-9/WD V0.5 IEC 4264 4265

Bit Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 7 2 31 2 23 2 15 27 2 31 2 23 2 15 27 MSB 6 2 30 2 22 2 14 26 2 30 2 22 2 14 26 5 2 29 2 21 2 13 25 2 29 2 21 2 13 25

233

Working Draft

Table E.14 Coding of TimeT

4 2 28 2 20 2 12 24 2 28 2 20 2 12 24 3 2 27 2 19 2 11 23 2 27 2 19 2 11 23 2 2 26 2 18 2 10 22 2 26 2 18 2 10 22 1 2 25 2 17 29 21 2 25 2 17 29 21 0 2 24 2 16 28 20 2 24 2 16 28 20 LSB MSB = Most significant bit LSB = Least significant bit Fractional part of seconds. One unit is 1/(2 32 ) s Definitions Seconds since 1900-01-01 0.00,00 or since 2036-02-07 6.28,16 when time value less than 0x9DFF4400.00000000

4266 4267 4268 4269 4270 4271 4272

Data type name TimeSpanT

E.2.9

TimeSpanT

A TimeSpanT corresponds to the data type NetworkTimeDifference in IEC 61158-6:2003. It is composed of a 32-bit integer value that provides the network time difference in seconds and of a 32-bit unsigned integer value that provides the fractional portion of seconds in 1/2 32 seconds. Table E.15 shows the definition and Table E.16 the coding of TimeSpanT. Table E.15 TimeSpanT
Value range Octet 1 to 4 (see Table E.16): -2 31 i (2 31 -1) Octet 5 to 8 (see Table E.16): 0 i (2 32 -1) NOTE Resolution s (Seconds) (1/2 32 ) s Length 8 octets (32 bit integer + 32 bit unsigned integer)

32 bit integer and 32 bit unsigned integer are normal computer science data types

4273 4274
Bit Octet 1 Octet 2 Octet 3 Octet 4 Octet 5 Octet 6 Octet 7 Octet 8 7 2 31 2 23 2 15 27 2 31 2 23 2 15 27 6 2 30 2 22 2 14 26 2 30 2 22 2 14 26

Table E.16 Coding of TimeSpanT

5 2 29 2 21 2 13 25 2 29 2 21 2 13 25 4 2 28 2 20 2 12 24 2 28 2 20 2 12 24 3 2 27 2 19 2 11 23 2 27 2 19 2 11 23 2 2 26 2 18 2 10 22 2 26 2 18 2 10 22 1 2 25 2 17 29 21 2 25 2 17 29 21 0 2 24 2 16 28 20 2 24 2 16 28 20 Fractional part of seconds as 32 bit unsigned integer. One unit is 1/(2 32 ) s. Definitions Seconds (s) as 32 bit integer

Working Draft
MSB

234
LSB

61131-9/WD V0.5 IEC

MSB = Most significant bit LSB = Least significant bit

4275 4276 4277 4278 4279 4280 4281 4282 4283 4284 4285

E.3
E.3.1

Composite data types

General

Composite data types are combinations of basic data types only. Requirements on how to handle these data structures in a consistent manner can be found in [3]. Composite data types consist of several basic data types in a packed manner within a sequence of octets. Unused bit space shall be padded with "0". E.3.2 ArrayT

An ArrayT addressed by an Index is a data structure with data items of the same data type. The individual data items are addressable by the Subindex. Subindex = 0 addresses the whole array within the Index space. The structuring rules for arrays are shown in Figure E.6.
1) 2) 3) The Subindex data items are packed in a row without gaps describing an octet sequence The highest Subindex data item n starts right-aligned within the octet sequence UIntegerT and IntegerT with a length of 58 bit and < 64 bit are not permitted

4286 4287 4288 4289 4290

Index 66

Figure E.6 Structuring rules for ArrayT Table E.17 shows an example for the access of an array. Its content is a set of parameters of the same basic data type. Table E.17 Example for the access of an ArrayT
Subindex 1 2 3 4 5 Offset 12 9 6 3 0 Data items 0x2 0x6 0x4 0x7 0x5 Data Type IntegerT, 'bitLength' = 3

4291
Transmission direction Bit 15 Bit 0

0 1 0 1 1 0 1 0 1 0 1 1 0 1

0 0 1 1 1 1 0 1 0 0 1 1 1 1 0 1

Bit offset:

12 "Subindex1"

6 "Subindex3"

"Subindex5"

4292 4293

"Subindex2"

"Subindex4"

Figure E.7 Example of an ArrayT data structure

61131-9/WD V0.5 IEC 4294 4295 4296 4297 4298 E.3.3 RecordT

235

Working Draft

A record addressed by an Index is a data structure with data items of different data types. The Subindex allows addressing individual data items within the record on certain bit positions to be defined via the IODD of the particular Device. The structuring rules for records are shown in Figure E.8.
4) 5) 6) 7) 8) 9) The Subindices within the IODD shall be listed in ascending order from 1 to n describing an octet sequence. Gaps within the list of Subindices are allowed. Bit offsets shall always be indicated within this octet sequence (may show no strict order in the IODD) The bit offset starts with the last octet within the sequence; this octet starts with offset 0 for the least significant bit and offset 7 for the most significant bit The following data types shall always be aligned on octet boundaries: Float32T, StringT, OctetStringT, TimeT, and TimeSpanT UIntegerT and IntegerT with a length of 58 bit shall always be aligned on one side of an octet boundary It is highly recommended for UIntegerT and IntegerT with a length of 8 bit to align always on one side of an octet boundary

10) It is highly recommended for UIntegerT and IntegerT with a length of < 8 bit not to cross octet boundaries

4299 4300 4301 4302 4303

Index 47 Subindex 1 2 3 NOTE

Figure E.8 Structuring rules for RecordT Table E.18 shows an example 1 for the access of a RecordT. It consists of varied parameters named "Status", "Text", and "Value". Table E.18 Example 1 for the access of a RecordT
Offset 88 32 0 0x23 0x45 H E L L O 0x00 0x00 Data items Data Type UIntegerT, 'bitLength' = 16 StringT, 'fixedLength' = 7 UIntegerT, 'bitLength' = 32 Name Status Text Value

0x56 0x12 0x22 0x34

'bitLength' and 'fixedLength' are defined in the IODD of the particular Device

4304 4305 4306 4307

Index 46 Subindex 1 2 3 NOTE 2 1 0

Table E.19 shows an example 2 for the access of a RecordT. It consists of varied parameters named "Level", "Min", and "Max". Figure E.9 shows the corresponding data structure. Table E.19 Example 2 for the access of a RecordT
Offset 0x32 FALSE TRUE 0xF1 Data items Data Type UIntegerT, 'bitLength' = 14 BooleanT BooleanT Name Level Min Max

'bitLength' is defined in the IODD of the particular Device

Working Draft
Transmission direction Bit 15

236

61131-9/WD V0.5 IEC

Bit 0

1 1 0 0 1 0 1 1 1 1 0 0 1 0 1 1

1 1 0 0 0 1 0 1 1 1 0 0 0 1 0 1

Bit offset: "Level"

2 1 0 "Min" "Max"

4308 4309 4310 4311 4312 4313

Index 45

Figure E.9 Example 2 of a RecordT structure Table E.20 shows an example 3 for the access of a RecordT. It consists of varied parameters named "Control" through "Enable". Figure E.10 illustrates the corresponding RecordT structure of example 3 with the bit offsets. Table E.20 Example 3 for the access of a RecordT
Subindex 1 2 3 4 5 6 7 8 NOTE Offset 32 33 34 35 38 16 8 0 Data items TRUE FALSE FALSE TRUE TRUE 0xF8 0x41 0xC3 0x23 Data Type BooleanT BooleanT BooleanT BooleanT BooleanT OctetStringT, 'fixedLength' = 2 StringT, 'fixedLength' = 1 OctetStringT, 'fixedLength' = 1 Name NewBit DR4 CR3 CR2 Control Setpoint Unit Enable

'fixedLength' is defined in the IODD of the particular Device

4314
Transmission direction Bit 39 Bit 0

0xF8 0xF8

0x23 0x23

0x41 0x41

0xC3 0xC3

Bit offset:

38

35

32 "Setpoint"

16 "Unit"

8 "Enable"

4315 4316 4317 4318

Figure E.10 Example 3 of a RecordT structure Figure E.11 shows a selective write request of a variable within the RecordT of example 3 and a write request of the complete RecordT (see A.5.7).

61131-9/WD V0.5 IEC

Selective write of a variable within the record

237
Write of a record Write request 0001 Write request 0010 0101 0x49 0xF8 0x23 0x41 0xC3 CHKPDU 1000

Working Draft

Index = 45

Index = 45 Subindex = 4 0x01 CHKPDU

4319 4320 4321

Figure E.11 Write requests for example 3

Working Draft 4322 4323 4324 4325 4326 4327

Part

238

61131-9/WD V0.5 IEC

Annex F ( normative) Structure of the Data Storage data object

Table F.1 illustrates the structure of a Data Storage (DS) data object within the Master (See 11.3.2). Table F.1 Structure of the stored DS data object
Parameter name ISDU_Index Object 1 ISDU_Subindex ISDU_Length ISDU_Data ISDU_Index Object 2 ISDU_Subindex ISDU_Length ISDU_Data Definition ISDU Index (0 to 65 535) ISDU Index (0 to 255) Length of the subsequent record Record of length ISDU_Length ISDU Index (0 to 65 535) ISDU Index (0 to 255) Length of the subsequent record Record of length ISDU_Length ---------ISDU_Index Object n ISDU_Subindex ISDU_Length ISDU _Data ISDU Index (0 to 65 535) ISDU Index (0 to 255) Length of the subsequent record Record of length ISDU_Length Unsigned16 Unsigned8 Unsigned8 Record Data type Unsigned16 Unsigned8 Unsigned8 Record Unsigned16 Unsigned8 Unsigned8 Record

4328 4329 4330 4331 4332 4333 The Device shall calculate the required memory size by summarizing the objects 1 to n (See Table B.9, Subindex 3). The Master shall store locally in non-volatile memory the header information shown in Table F.2. See Table B.9. Table F.2 Associated header information for stored DS data objects
Part Header Parameter name Parameter Checksum VendorID DeviceID FunctionID Definition 32 bit CRC signature or revision counter (10.4.8) See B.1.9 See B.1.10 See B.1.11 Data type Unsigned32 Unsigned16 Unsigned32 Unsigned16

4334

61131-9/WD V0.5 IEC 4335 4336 4337 4338 4339 4340 4341 4342 4343 4344 4345 4346 4347 4348 4349 4350 4351 4352 4353 4354 4355 4356 4357 4358 4359 4360 4361 4362 4363 4364 4365 4366

239

Working Draft

Annex G ( normative) Master and Device conformity

G.1
G.1.1

Conformance classes
Overview

To be defined in conjunction with [14]. G.1.2 Functional requirements for Devices

To be defined in conjunction with [14]. G.1.3 Functional requirements for Master

To be defined in conjunction with [14].

G.2
G.2.1

Electromagnetic compatibility requirements (EMC)

General

The EMC requirements of this specification are only relevant for the SDCI interface part of a particular Master or Device. The technology functions of a Device and its relevant EMC requirements are not in the scope of this specification. For this purpose the Device specific product standards shall apply. For Master usually the EMC requirements for peripherals are defined in IEC 61131-2 or IEC 61000-6-2. To ensure proper operating conditions of the SDCI interface, the test configurations defined in section G.2.6 (Master) or G.2.7 (Device) shall be maintained during all the EMC tests. The tests required in the product standard of equipment under test (EUT) can alternatively be performed in SIO mode. G.2.2 Operating conditions

It is highly recommended to evaluate the SDCI during the startup phase with the cycle times given in Table G.1. In most cases, this leads to the minimal time requirements for the performance of these tests. Alternatively, a manufacturer can decide to evaluate the SDCI during normal operation of the Device, but then he shall confirm that the required number of F-sequences specified in Table G.1 took place during each test. G.2.3 Performance criteria

a) Performance criterion A The SDCI operating at an average cycle time as defined in Table G.1 shall not show more than six detected F-sequence errors within the number of F-sequences given in Table G.1. No interruption of communication is permitted.

Working Draft 4367

Transmission rate

240 Table G.1 EMC test conditions for SDCI

Master t CYC Number of F-sequences of TYPE_2_5 (read) (6 octets) 300 (6 000) 450 (9 000) 700 (14 000) t CYC Device

61131-9/WD V0.5 IEC

Number of F-sequences of TYPE_0 (read) (4 octets) 350 (7 000) 500 (10 000) 800 (16 000)

Maximum of Fsequence errors

4,8 Kbit/s 38,4 Kbit/s 230,4 Kbit/s

18,0 ms 2,3 ms 0,4 ms

100 T BIT (20,84 ms) 100 T BIT (2,61 ms) 100 T BIT (0,44 ms)

6 6 6

NOTE The numbers of F-sequences are calculated according to the algorithm in H.2 and rounded up. The larger number of F-sequences (in brackets) are required if a certain test (for example fast transients/burst) applies interferences only with a burst/cycle ratio (see Table G.2)

4368 4369 4370 4371 4372 4373 4374

Phenomena Electrostatic discharges (ESD) IEC 61000-4-2

b) Performance Criterion B The error rate of criterion A shall also be satisfied after but not during the test. No change of actual operating state (e.g. permanent loss of communication) or stored data is allowed. G.2.4 Required immunity tests

Table G.2 specifies the EMC tests to be performed. Table G.2 EMC test levels
Test Level Air discharge: 8 kV Contact discharge: 4 kV Radio-frequency electromagnetic field. Amplitude modulated IEC 61000-4-3 80 MHz 1 000 MHz 10 V/m 1 400 MHz 2 000 MHz 3 V/m 2 000 MHz 2 700 MHz 1 V/m Fast transients (Burst) IEC 61000-4-4 1 kV 2 kV A B 5 kHz only. The number of F-sequences in Table G.1 shall be increased by a factor of 20 due to the burst/cycle ratio 15 ms/300 ms. See NOTE 3 A See NOTE 1 and NOTE 2 B Performance Criterion Constraints See NOTE 1

Surge IEC 61000-4-5 Radio-frequency common mode IEC 61000-4-6 Voltage dips and interruptions IEC 61000-4-11

Not required for an SDCI link (SDCI link is limited to 20 m) 0,15 MHz 80 MHz 10 VEMF A

See NOTE 2 and NOTE 4

Not required for an SDCI link

61131-9/WD V0.5 IEC

Phenomena

241
Test Level Performance Criterion

Working Draft
Constraints

NOTE 1 As this phenomenon influences the entire device under test, an existing device specific product standard takes precedence over the test levels specified here. NOTE 2 The test shall be performed with a step size of 1 % and a dwell of 1 s. If a single F-sequence error occurs at a certain frequency, that frequency shall be tested until the number of F-sequences according Table G.1 has been transmitted or until 6 F-sequence errors have occurred. NOTE 3 Depending on the transmission rate the test time varies. The test time shall be at least one minute (with the transmitted F-sequences and the permitted errors increased accordingly). NOTE 4 This phenomenon is expected to influence most probably the EUTs internal analog signal processing and only with a very small probability the functionality of the SDCI communication. Therefore an existing device specific product standard takes precedence over the test levels specified here.

4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 G.2.5 Required emission tests

The definition of emission limits is not in the scope of this specification. The requirements of the Device specific product family or generic standards apply, usually for general industrial environments the IEC 61000-6-4. All emission tests shall be performed at the fastest possible communication rate with the fastest cycle time. G.2.6 G.2.6.1 Test configurations for Master General rules

The following rules apply for the test of Masters: In the following test setup diagrams only the SDCI and the power supply cables are shown. All other cables shall be treated as required by the relevant product standard. Grounding of the Master and the Devices shall be according to the relevant product standard or manual. Where not otherwise stated, the SDCI cable shall have an overall length of 20 m. Excess length laid as an inductive coil with a diameter of 0,3 m, where applicable mounted 0,1 m above reference ground. Where applicable, the auxiliary Devices shall be placed 10 cm above RefGND. A typical test configuration consists of the Master and two Devices, except for the RF common mode test, where only one Device shall be used. Each port shall fulfill the EMC requirements. Electrostatic discharges

G.2.6.2

Figure G.1 shows the test setup for electrostatic discharge according IEC 61000-4-2.
AUX 1 (Device) AUX 2 (Device)

Power Supply

EUT (Master)

D=0,3 m

4398 4399

d 1,0 m

d 1,0 m

Figure G.1 Test setup for electrostatic discharge (Master)

Working Draft 4400 4401 4402 G.2.6.3

242

61131-9/WD V0.5 IEC

Radio-frequency electromagnetic field

Figure G.2 shows the test setup for radio-frequency electromagnetic field according IEC 61000-4-3.

Power Supply Uniform area l = 1,0 m

EUT (Master)

AUX 1 (Device) AUX 2 (Device)

l = 1,0 m

D=0,3 m

4403 4404 4405 4406 G.2.6.4

Ferrite clamp or other decoupling

Figure G.2 Test setup for RF electromagnetic field (Master) Fast transients (burst)

Figure G.3 shows the test setup for fast transients according IEC 61000-4-4.
CCC CDN EUT (Master) AUX 1 (Device) AUX 2 (Device)

Power Supply

D=0,3 m

4407 4408 4409 4410 4411 4412 4413

NOTE 1 NOTE 2 NOTE 3

l = 0,5 m

l = 0,5 m

l = 0,5 m

Figure G.3 Test setup for fast transients (Master)

No coupling into SDCI line to AUX 2 is required CDN: Coupling/Decoupling Network CCC: Capacitive coupling clamp

G.2.6.5

Radio-frequency common mode

Figure G.4 shows the test setup for radio-frequency common mode according IEC 61000-4-6.
EM-Clamp CDN EUT (Master) AUX 1 (Device)

Power Supply

4414 4415 4416 4417 4418

NOTE 1 NOTE 2

Figure G.4 Test setup for RF common mode (Master)

0,1 m < x < 0,3 m SDCI overall cable length = 1 m

61131-9/WD V0.5 IEC 4419 4420 4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 G.2.7.2 Electrostatic discharges G.2.7 G.2.7.1 Test configurations for Devices General rules

243

Working Draft

For the test of Devices the following rules apply: In the following test setup diagrams only the SDCI and the power supply cables are shown. All other cables shall be treated as required by the relevant product standard. Grounding of the Master and the Devices according to the relevant product standard or user manual. Where not otherwise stated, the SDCI cable shall have an overall length of 20 m. Excess length laid as an inductive coil with a diameter of 0,3 m, where applicable mounted 0,1 m above RefGND. Where applicable, the auxiliary Devices shall be placed 10 cm above RefGND. Test with Device AUX 2 is optional

Figure G.5 shows the test setup for electrostatic discharge according to IEC 61000-4-2.

Power Supply

AUX 1 (Master)

EUT (Device)

4434 4435 4436 4437 4438 G.2.7.3

AUX 2 (Device)

D=0,3 m d 1,0 m

Figure G.5 Test setup for electrostatic discharges (Device) Radio-frequency electromagnetic field

Figure G.6 shows the test setup for radio-frequency electromagnetic field according to IEC 61000-4-3.

Power Supply

AUX 1 (Master)

EUT (Device)

AUX 2 (Device)

D=0,3 m Ferrite clamp or other decoupling l = 1,0 m Uniform area

4439 4440 4441 4442 G.2.7.4

Figure G.6 Test setup for RF electromagnetic field (Device) Fast transients (burst)

Figure G.7 shows the test setup for fast transients according IEC 61000-4-4.

Working Draft

244

61131-9/WD V0.5 IEC

Power Supply

CDN

AUX 1 (Master)

CCC

EUT (Device)

AUX 2 (Device)

D=0,3 m l = 0,5 m l = 0,5 m

4443 4444 4445 4446 4447 4448

NOTE 1 NOTE 2

Figure G.7 Test setup for fast transients (Device)

CDN: Coupling/Decoupling Network, here only used for decoupling CCC: Capacitive coupling clamp

G.2.7.5

Radio-frequency common mode

Figure G.8 shows the test setup for radio-frequency common mode according IEC 61000-4-6.
EM-Clamp CDN AUX 1 (Master) DUT (Device)

Power Supply

4449 4450 4451 4452 4453 4454 4455 4456 4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467 4468 4469 4470
NOTE 1 NOTE 2

Figure G.8 Test setup for RF common mode (Device)

0,1 m < x < 0,3 m SDCI overall cable length = 1 m

G.3
G.3.1

Test strategies for conformity

General

Detailed instructions for the Master and Device tests are specified in [14]. G.3.2 Test of a Device

The Master AUX 1 (Figure G.5 ff) shall continuously send an F-sequence TYPE_0 (read Direct Parameter page 2) message at the cycle time defined in Table G.1 and count the missing and the erroneous Device responses. Both numbers shall be added and indicated. G.3.3 Test of a Master

The Device AUX 1 (Figure G.1 ff) shall use F-sequence TYPE_2_5. Its input Process Data shall be generated by an 8 bit random or pseudo random generator. The Master shall copy the input Process Data of any received Device message to the output Process Data of the next Master message to be sent. The cycle time shall be according to Table G.1. The Device AUX 1 shall compare the output Process Data with the previously sent input Process Data and count the number of deviations. The Device shall also count the number of missing (not received within the expected cycle time) or received perturbed Master messages. All numbers shall be added and indicated.
NOTE A deviation of sent and received Process Data indicates to the AUX1 that the EUT (Master) did not receive the Device message.

61131-9/WD V0.5 IEC 4471 4472

245

Working Draft

G.4

Manufacturer declaration

Figure G.9 shows a layout proposal for a manufacturer's declaration of conformity. (Consortium logo)

MANUNFACTURER'S DECLARATION OF CONFORMITY

(Company logo)

WE:

Company's name and address declare under our own responsibility that the product(s): Trademark, IO-Link product types (annotate "IO-Link Master" or "IO-Link Device") to which this declaration refers conform to: IO-Link Interface and System Specification, V1.1, <month> 2010 IO Device Description, V1.1, <month> 2010 IEC 61000-6-2 (IEC 61131-2) IEC 60947-5-2
(see NOTE 2) (see NOTE 1)

The conformity tests are documented in the test report: Testreport identification Issued at location, date Name: Title: Signature: Authorized signatory First, last name Job title Signature

Reproduction and all distribution without written authorization prohibited 4473 4474 4475
NOTE 1 NOTE 2 Relevant EMC standards in case of a Master Relevant EMC standard in case of a Device, other product standards possible

Figure G.9 Layout proposal for a manufacturer's declaration

Working Draft 4476 4477 4478 4479 4480 4481 4482 4483

246

61131-9/WD V0.5 IEC

Annex H (informative) Residual error probabilities

H.1 Residual error probability of the SDCI data integrity mechanism

Figure H.1 shows the residual error probability (REP) of the SDCI data integrity mechanism consisting of the checksum data integrity procedure ("XOR6") as defined in A.1.6 and the UART parity. The diagram refers to IEC 60870-5-1 [6] with its data integrity class I2 for a minimum Hamming distance of 4 (red dotted line).
1 0,1 0,01 1* 10-3 Residual error probability (R) 1* 10-4 1* 10-5 1* 10-6 1* 10-7 1* 10-8 1* 10-9 1* 10-10 1* 10-11 Key SDCI with 2 octets SDCI with 3 octets SDCI with 4 octets Hamming distance 4 Integrity class I2

1* 10-12 1* 10-13 1* 10-4 1* 10-3

0,01

0,1

4484 4485 4486 4487 4488 4489 4490 4491 4492 4493 4494 4495 4496

Bit error probability (BEP)

Figure H.1 Residual error probability for the SDCI data integrity mechanism The blue line shows the residual error curve for a data length of 2 octets. The black curve shows the residual error curve for a data length of 3 octets. The purple curve shows the residual error curve for a data length of 4 octets.

H.2

Derivation of EMC test conditions

The performance criterion A in G.2.3 is derived from requirements defined in IEC 61158-2 in respect to interference susceptibility and error rates (citation): Only 1 undetected erroneous frame in 20 years at 1 600 frames/s The ratio of undetected to detected frames shall not exceed 10 -6 EMC tests shall not show more than 6 erroneous frames within 100 000 frames

With SDCI, the first requirement transforms into the equation (H.1). This equation allows determining a value of BEP. The equation can be resolved in a numerical way.

61131-9/WD V0.5 IEC

247

Working Draft

F20 R(BEP ) 1
4497 4498 4499 4500 4501 4502 4503 4504 4505 The Terms in equation (H.1) are: F20 R(BEP) BEP = Number of frames in 20 years

(H.1)

= Residual error probability of the checksum and parity mechanism (Figure H.1) = Bit error probability from Figure H.1

The objective of the EMC test is to proof that the BEP of the SDCI communication meets the value determined in the first step. The maximum number of detected perturbed frames is chosen to be 6 here for practical reasons. The number of required SDCI test frames can be determined with the help of equation (H.2) and the value of BEP determined in the first step.

NoTF
4506 4507 4508 4509 4510 4511 4512 4513

1 1 NopErr BEP BitPerF

(H.2)

The Terms in equation (H.2) are: NoTF BitPerF NopErr = Number of test frames = Number of bit per frame = Maximum number of detected perturbed frames = 6

Equation (H.2) is only valid under the assumption that frames with 1 bit error are more frequent than frames with more bit errors. An F-sequence consists of two frames. Therefore, the calculated number of test frames has to be divided by 2 to provide the numbers of Fsequences for Table G.1.

Working Draft 4514 4515 4516 4517 4518 4519 4520

Master FC comment (state, action) (see in Table 46) Idle_1 ISDURequest_2, transmission, ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDUWait_3, start ISDU Timer ISDUWait_3, inc. ISDU timer ISDUWait_3, inc. ISDU timer ISDUWait_3, inc. ISDU timer ISDUWait_3, inc. ISDU timer ISDUResponse_4, reception Stop ISDU Timer ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, no response, retry in next cycle ISDUResponse_4, no response, retry in next cycle ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception, start eventhandler Read_Event_2, reception Read_Event_2, reception cycle R nr W Chan. CTRL Typ 1bit 2bit 5bit 2bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 34 35 36 37 CKT PD Process Data 8bit

248

61131-9/WD V0.5 IEC

Annex I ( informative) Example sequence of an ISDU transmission

Figure I.1 and Figure I.2 illustrate an example for the transmission of ISDUs using an AL_Read service with a 16-bit Index and Subindex for 19 octets of user data with mapping to an F-sequence TYPE_2_5 for sensors and with interruption in case of an event transmission.

Device OD Master 8bit OD Device 8bit PD Process Data E PD CKS CHK comment (state, action) OnReq idle ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDUWait_3, application busy ISDUWait_3, application busy ISDUWait_3, application busy ISDUWait_3, application busy ISDUWait_3, application busy ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, korrupted CHK, don' t send resp. ISDUResponse_4, corrupted CHK, don' t send resp. ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission, freeze event Read_Event_2, transmission Read_Event_2, transmission ComandHandler_2, reception, set PDOutdata state to invalid Read_Event_2, transmission Read_Event_2, transmission OnReq Data

Com Flow Frame CHK 6bit

1111 0001 0111 0000 0110 0001 0110 0010 0110 0011 0110 0100 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1110 0001 1110 0010 1110 0011 1110 0100 1110 0101 1110 0110 1110 0111 1110 1000 1110 1001 1110 1001 1110 1001 1110 1010 1110 1011 1100 0000 110x xxxx 0010 0000 110x xxxx 110x xxxx 0100 0000 1110 1100 1110 1101 1110 1110 1110 1111 1110 0000 1110 0001 1110 0010 1111 0001 1111 0001 1111 0001 1111 0001 0011 0000 1011 0000 1111 0001 1111 0001 1111 0001

10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10

xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
Err

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

0000 0000 1011 0101

Index(hi) Index(lo) Subindex CHKPDU

0000 0001 0000 0001 0000 0001 0000 0001 0000 0001 1101 0001 0001 0011
Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx

10 Err 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 xxxxxx 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx

Data 8 Data 9 Data 10

Diag State with detail Event qualifier

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

xxxxxx 0 0 xxxxxx 0 0 xxxxxx 1 0 xxxxxx 1 0 xxxxxx 1 0 xxxxxx 1 0 xxxxxx 1 0 xxxxxx 1 0 xxxxxx 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx

Command handler_2, transmission set PDOutdata state to invalid 38 Read_Event_2, reception Read_Event_2, reception EventConfirmation_4, transmission, event handler idle ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, reception Idle_1 Idle_1 Idle_1 Idle_1 Write Parameter, transmission Read Parameter, reception Idle_1 Idle_1 39 40

1001 1001
ErrorCode msb ErrorCode lsb

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57

xxxxxxxx
Data 11 Data 12 Data 13 Data 14 Data 15 Data 16 CHKPDU

EventConfirmation, reception ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission Idle_1 Idle_1 Idle_1 Idle_1 Write Parameter, reception Read Parameter, transmission Idle_1 Idle_1 Idle_1

0000 0000 0000 0000 0000 0000 0000 0000 xxxxxxxx xxxxxxxx 0000 0000 0000 0000 0000 0000

4521 4522

Idle_1

Figure I.1 Example for ISDU transmissions

61131-9/WD V0.5 IEC

ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDUWait_3, start ISDU Timer ISDUResponse_4, reception Stop ISDU Timer ISDUResponse_4, reception Idle_1 Idle_1 ISDURequest_2, transmission, ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDURequest_2, transmission ISDUWait_3, start ISDU Timer ISDUWait_3, inc. ISDU timer ISDUWait_3, inc. ISDU timer ISDUWait_3, inc. ISDU timer ISDUWait_3, inc. ISDU timer ISDUResponse_4, reception Stop ISDU Timer ISDUResponse_4, reception ISDUResponse_4, reception ISDUResponse_4, ABORT Idle_1 Idle_1 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89

249
10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 0001 1011
Index Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8 CHKPDU

Working Draft
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDUWait_3, application busy ISDUResponse_4, transmission ISDUResponse_4, transmission Idle_1 Idle_1 ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDURequest_2, reception ISDUWait_3, application busy ISDUWait_3, application busy ISDUWait_3, application busy ISDUWait_3, application busy ISDUWait_3, application busy ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, transmission ISDUResponse_4, ABORT Idle_1 Idle_1

0111 0000 0110 0001 0110 0010 0110 0011 0110 0100 0110 0101 0110 0110 0110 0111 0110 1000 0110 1001 0110 1010 1111 0000 1111 0000 1110 0001 1111 0001 1111 0001 0111 0000 0110 0001 0110 0010 0110 0011 0110 0100 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1110 0001 1110 0010 1111 1111 1111 0001 1111 0001

0000 0001 0101 0010

CHKPDU

0000 0000 0000 0000 1011 0101

Index(hi) Index(lo) Subindex CHKPDU

0000 0001 0000 0001 0000 0001 0000 0001 0000 0001 1101 0001 0001 1110
Data 1

4523 4524

0000 0000 0000 0000 0000 0000

Figure I.2 Example for ISDU transmissions (continued)

Working Draft 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540 4541

250

61131-9/WD V0.5 IEC

Annex J ( informative) Recommended methods for detecting parameter changes

J.1 CRC signature

Cyclic Redundancy Checking belongs to the HASH function family. A CRC signature across all changeable parameters can be calculated by the Device with the help of a so-called proper generator polynomial. The calculation results in a different signature whenever the parameter set has been changed. It should be noted that the signature secures also the octet order within the parameter set. Any change in the order when calculating the signature will lead to a different value. The quality of securing (undetected changes) depends heavily on both the CRC generator polynomial and the length (number of octets) of the parameter set. The seed value should be > 0. One calculation method uses directly the formula, another one uses octet shifting and lookup tables. The first one requests less program memory and is a bit slower, the other one requires memory for a lookup table (1 * 2 10 octets for a 32 bit signature) and is fast. The parameter data set comparison is performed in state "Checksum_9" of the Data Storage (DS) state machine in Figure 96. Table J.1 Proper CRC generator polynomials
Generator polynomial 0x9B 0x4EAB 0x5D6DCB 0xF4ACFB13 Signature 8 bit 16 bit 24 bit 32 bit Data length 1 octet 1 < octets < 3 1 < octets < 4 1 < octets < 2 32 Undetected changes < 2 -8 (not recommended) < 2 -16 (not recommended) < 2 -24 (not recommended) < 2 -32 (recommended)

4542 4543 4544 4545 4546 4547 4548 4549 4550 4551

J.2

Revision counter

A 32 bit revision counter can be implemented, counting any change of the parameter set. The Device shall use a random initial value for the Revision Counter. The counter itself shall not be stored via Index List of the Device. After the download the actual counter value is read back from the Device to avoid multiple writing initiated by the download sequence. The parameter data set comparison is performed in state "Checksum_9" of the Data Storage (DS) state machine in Figure 96.

61131-9/WD V0.5 IEC 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565

251

Working Draft

Annex K (informative) Information on conformity testing of SDCI

Information about testing Masters and Devices for conformity with IEC 61131-9 can be obtained from the National Committees of the IEC or from the following organization: IO-Link Consortium Haid-und-Neu-Str. 7 76131 Karlsruhe Germany Phone: +49 (0) 721 / 96 58 590 Fax: +49 (0) 721 / 96 58 589 E-mail: info@io-link.com Web site: http://www.io-link.com

Working Draft 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584 4585 4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609

252

61131-9/WD V0.5 IEC

Bibliography
List below all documents referenced from informative text in this document (including those referenced in definitions), as well as other documents providing background information that may be useful for understanding the standard. These bibliographic references shall be ordered in ascending order within the following groups: IEC, then ISO/IEC, then ISO, then other organizations by alphabetical order. The examples provided below include automatic numbering of the documents, using a dedicated caption label Reference (for easy update and referencing within the text). If this caption label is not known in your environment, you can add it as follows: 1) Put your cursor on a new line 2) From the main menu, select Insert Reference - Caption, then select New label, then enter the string Reference as new label, then OK twice. 3) Delete the (un-useful) line that was just created (the new label will still be remembered). To insert a cross-reference to a bibliographic entry, you may then use Insert crossreference, then select the Reference label, and the entry you want to reference. If you select the option Only number and label, you will need to insert the closing bracket ] manually after the reference. [1] IEC 60050 (all parts), International Electrotechnical Vocabulary
NOTE See also the IEC Multilingual Dictionary Electricity, Electronics and Telecommunications (available on CD-ROM and at <http://domino.iec.ch/iev>).

[2] IEC/TR 62453-61, Field device tool interface specification Device Type Manager (DTM) Styleguide for common object model [3] IO-Link Consortium, IO Device Description (IODD), V1.0, Order No. 10.012 [4] IEC/TR 62390: 2005, Common automation device profile guideline [5] ISO/IEC DIS 19505:2009 Information technology OMG Unified Modeling Language (OMG UML) Version 2.1.2 [6] IEC 60870-5-1:1990, Telecontrol equipment and systems. Part 5: Transmission protocols - Section One: Transmission frame formats [7] "The Unicode Standard", V5.0 [8] Internet Engineering Task Force (IETF): RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis; available at < www.ietf.org > [9] IEC 61158-6:2003, Digital data communication for measurement and control Fieldbus for use in industrial control systems Part 6: Application Layer protocol specification [10] ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic [11] ISO/IEC 646:1991, Information technology ISO 7-bit coded character set for information interchange [12] IO-Link Consortium, IO-Link Device Profiles, Vx.y 4 [13] IO-Link Consortium, IO-Link Communication, V1.0, January 2009, Order No. 10.002 [14] IO-Link Consortium, IO-Link Test Specification, Vx.y 4 [15] Adrian Farrel, The Internet and its Protocols: A Comparative Approach, Morgan Kaufmann, ISBN-13 978-1558609136 [16] NE107, Self-Monitoring and Diagnosis of Field Devices, June 2006, <www.namur.de> ____________

4 In progress

 Copyright by: IO-Link Consortium Haid-und-Neu-Str. 7 76131 Karlsruhe Germany Phone: +49 (0) 721 / 96 58 590 Fax: +49 (0) 721 / 96 58 589 e-mail: info@io-link.com http://www.io-link.com/