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 (TÜV, 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:
[email protected] 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
2
of
253
61131-9/WD V0.5 IEC
–3–
Working Draft
CONTENTS
FOREWORD.......................................................................................................................15 0
Introduction ..................................................................................................................17
1
0.1 General ...............................................................................................................17 0.2 Patent declaration ...............................................................................................18 Scope ..........................................................................................................................19
2
Normative references ...................................................................................................19
3
Terms, definitions, symbols, abbreviated terms and conventions ...................................20
4
Overview of SDCI (IO-Link TM ) .......................................................................................28
5
Physical Layer (PL) ......................................................................................................34
6
Standard Input and Output (SIO)...................................................................................48
7
Data link layer ..............................................................................................................48
8
Application layer ...........................................................................................................92
9
System management (SM) .......................................................................................... 111
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
–4–
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
–5–
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
–6–
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
–7–
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
–8–
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
–9–
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
Report on voting
XX/XX/NP
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
0 0.1
– 17 –
Working Draft
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
– 18 –
61131-9/WD V0.5 IEC
Patent declaration
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
[AB]
Fieldbus connecting system for actuators or sensors
DE 100 54 288 A1
[FE]
Sensoranordnung zur Erfassung wenigstens eines Messwerts
DE 102005 014783 A1
[SI]
Verfahren und Vorrichtungen zum Übertragen von Daten auf einer Datenleitung zwischen einem Steuergerät und zumindest einem dezentralen Datenverarbeitungsgerät
DE 102004 035831 A1
[SI]
Verfahren und Vorrichtung zur Inbetriebnahme eines Geräts
DE 102 119 39 A1 US 2003/0200323 A1
[SK]
Coupling apparatus for the coupling of devices to a bus system
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
[FE]
Festo AG Esslingen Germany
[SI]
Siemens AG I IA AS FA TC Karlsruhe Germany
[SK]
Sick AG Waldkirch Germany
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
– 19 –
Working Draft
1 2 3 4 5 6
Part 9: Single-drop digital communication interface for small sensors and actuators (SDCI)
7
1
PROGRAMMABLE CONTROLLERS —
Scope
8 9 10 11 12 13 14 15 16 17 18 19 20
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.
21 22 23 24
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.
25 26
This version also includes EMC test requirements, and a template for the manufacturer's conformity declaration.
27
2
28 29 30
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.
31 32
IEC 60947-5-2, Low-voltage switchgear and controlgear – Part 5-2: Control circuit devices and switching elements – Proximity switches
33 34
IEC 61000-4-2, Electromagnetic compatibility (EMC) – Part 4-2: Testing and measurement techniques – Electrostatic discharge immunity test
35 36
IEC 61000-4-3, Electromagnetic compatibility (EMC) – Part 4-3: Testing and measurement techniques – Radiated, radio-frequency, electromagnetic field immunity test
37 38
IEC 61000-4-4, Electromagnetic compatibility (EMC) – Part 4-4: Testing and measurement techniques – Electrical fast transient/burst immunity test
39 40
IEC 61000-4-5, Electromagnetic compatibility (EMC) – Part 4-5: Testing and measurement techniques – Surge immunity test
41 42
IEC 61000-4-6, Electromagnetic compatibility (EMC) – Part 4-6: Testing and measurement techniques – Immunity to conducted disturbances, induced by radio-frequency fields
Normative references
Working Draft
– 20 –
61131-9/WD V0.5 IEC
43 44
IEC 61000-6-4, Electromagnetic compatibility (EMC) – Part 6: Generic standards – Section 4: Emission standard for industrial environments
45 46
IEC 61076-2-101, Connectors for electronic equipment – Product requirements – Part 2-101: Circular connectors - Detail specification for M12 connectors with screw-locking
47
IEC 61131-2, Programmable controllers – Part 2: Equipment requirements and tests
48 49
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
50 51
IEC 61158-3, Digital data communications for measurement and control – Fieldbus for use in industrial control systems – Part 3: Data link layer service definition
52 53
IEC 61158-4, Digital data communications for measurement and control – Fieldbus for use in industrial control systems – Part 4: Data link layer protocol specification
54 55
IEC 61158-5, Digital data communications for measurement and control – Fieldbus for use in industrial control systems – Part 5: Application layer service definition
56 57
IEC 61158-6, Digital data communications for measurement and control – Fieldbus for use in industrial control systems – Part 6: Application layer protocol specification
58 59
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
60 61
ISO/IEC 10731, Information technology – Open Systems Interconnection – Basic Reference Model – Conventions for the definition of OSI services
62 63
ISO/IEC 7498-1, Information technology – Open Systems Interconnection – Basic Reference Model – Part 1: The Basic Model
64 65
3
66
3.1
67 68
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.
69 70 71 72
3.1.1 address part of the F-sequence control to reference data within data categories of a communication channel
73 74 75 76
3.1.2 application layer (AL) part of the protocol responsible for the transmission of Process Data objects and OnRequest Data objects
77 78 79
3.1.3 block parameter consistent parameter access via multiple Indices or Subindices
Terms, definitions, symbols, abbreviated terms and conventions Terms and definitions
61131-9/WD V0.5 IEC
– 21 –
Working Draft
80 81 82 83
3.1.4 checksum complementary part of the overall data integrity measures in the data link layer in addition to the UART parity bit
84 85 86 87
3.1.5 CHKPDU integrity protection data within an ISDU communication channel generated through XOR processing the octets of a request or response
88 89 90
3.1.6 coded switching SDCI communication, based on the standard binary signal levels of IEC 61131-2
91 92 93
3.1.7 COM1 transmission rate of 4,8 kbit/s
94 95 96
3.1.8 COM2 transmission rate of 38,4 kbit/s
97 98 99
3.1.9 COM3 transmission rate of 230,4 kbit/s
100 101 102
3.1.10 COMx one out of three possible transmission rates COM1, COM2, or COM3
103 104 105
3.1.11 communication error unexpected disturbance of the SDCI transmission protocol
106 107 108 109
3.1.12 cycle time time to transmit an F-sequence between a Master and its Device including the following idle time
110 111 112
3.1.13 communication channel logical connection between Master and Device
113 114
NOTE Four communication channels are defined: process channel, page and ISDU channel (for parameters) and diagnosis channel.
115 116 117
3.1.14 Device single passive peer to a Master such as a sensor or actuator
118
NOTE
119 120 121 122
3.1.15 direct parameters directly (page) addressed parameters transferred acyclically via the page communication channel without acknowledgement
Uppercase "Device" is used for SDCI equipment, while lowercase "device" is used in a generic manner.
Working Draft
– 22 –
61131-9/WD V0.5 IEC
123 124 125 126
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
127 128 129
3.1.17 event an instance of a change of conditions
130 131
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.
132
[IEC 61158-5-x, modified]
133 134 135
3.1.18 fallback transition of a port from coded switching to switching signal mode
136 137 138 139
3.1.19 F-sequence sequence of two messages (frames) comprising a Master message and its subsequent Device message
140 141 142 143
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
144 145 146
3.1.21 F-sequence error unexpected or wrong frame content, or no response
147 148 149
3.1.22 F-sequence type one particular F-sequence format out of a set of specified F-sequence formats
150 151 152
3.1.23 frame denigrated synonym for data-link PDU
153
[IEC 61158-3-x]
154 155 156
3.1.24 framing error perturbed UART frames (physical layer)
157 158 159 160
3.1.25 interleave segmented cyclic data exchange for process data with more than 2 octets through subsequent cycles
161 162 163 164
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
– 23 –
Working Draft
165 166 167 168
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
169
NOTE
170 171 172 173
3.1.28 message coherent set of UART frames transferred either from a Master to its Device or vice versa following the rules of the SDCI protocol
174 175 176 177
3.1.29 on-request data acyclically transmitted data upon request of the Master application consisting of parameters or event data
178 179 180 181
3.1.30 PHY-3W three wire connection to Devices for power, ground, communication and/or switching signals defined in IEC 60947-5-2
182 183 184 185 186
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
187
NOTE
188
[ISO/IEC 7498-1, modified]
189 190 191
3.1.32 port communication medium interface of the Master to one Device
192 193 194
3.1.33 port operating mode state of a Master's port that can be either INACTIVE, DO, DI, SDCI, or ScanMode
195 196 197 198 199
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
200 201 202 203
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)
204 205 206
3.1.36 single parameter independent parameter access via one single Index or Subindex
207 208 209 210
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
Uppercase "Master" is used for SDCI equipment, while lowercase "master" is used in a generic manner.
Physical layer provides means for wake-up and fallback procedures.
Working Draft
– 24 –
61131-9/WD V0.5 IEC
211 212 213 214
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
215 216 217 218
3.1.39 switching signal binary signal from or to a Device when in SIO mode (as opposed to the "coded switching" SDCI communication)
219 220 221 222
3.1.40 system management (SM) means to control and coordinate the internal communication layers and the exceptions within the Master and its ports, and within each Device
223 224 225 226
3.1.41 UART frame 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
227 228 229
3.1.42 wake-up procedure for causing a Device to change its mode from SIO to SDCI
230 231 232 233
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
234
3.2
Symbols and abbreviated terms
f DTR
Permissible deviation from data transfer rate, measured in %
PS
Power supply ripple, measured in V
AL
Application Layer
BEP
Bit error probability
C/Q
Connection for communication (C) or switching (Q) signal (SIO)
CL eff
Effective total cable capacity, measured in nF
CQ
Input capacity at C/Q connection, measured in nF
DI
Digital input
DL
Data Link Layer
DO
Digital output
f DTR
Data transfer rate, measured in bit/s
H/L
High/low signal at receiver output
I/O
Input / output
ILL
Input load current at input C/Q to V0, measured in A
IQ
Driver current in saturated operating status ON, measured in A
IQH
Driver current on high-side driver in saturated operating status ON, measured in A
IQL
Driver current on low-side driver in saturated operating status ON, measured in A
IQPK
Maximum driver current in unsaturated operating status ON, measured in A
IQPKH
Maximum driver current on high-side driver in unsaturated operating status ON, measured in A
IQPKL
Maximum driver current on low-side driver in unsaturated operating status ON,
61131-9/WD V0.5 IEC
– 25 –
Working Draft
measured in A IQQ
Quiescent current at input C/Q to V0 with inactive output drivers, measured in A
IQ WU
Amplitude of Master’s wake-up request current, measured in A
IS
Supply current at V+, measured in A
ISIR
Current pulse supply capability at V+, measured in A
LED
Light emitting diode
L-
Ground connection
L+
Power supply connection
n WU
Wake-up retry count
On/Off
Driver’s ON/OFF switching signal
ON-REQ
On-request data
OVD
Signal Overload Detect
PDCT
Port and Device configuration tool
PL
Physical layer
PLC
Programmable logic controller
PS
Power supply, measured in V
r
Time to reach a stable level with reference to the beginning of the start bit, measured in T BIT
RL eff
Loop resistance of cable, measured in Ω
s
Time to exit a stable level with reference to the beginning of the start bit, measured in T BIT
SDCI
Single-drop digital communication interface
SIO
Standard Input Output (digital switching mode)
SM
System Management
t1
Character transfer delay on Master, measured in T BIT
t2
Character transfer delay on Device, measured in T BIT
tA
Response delay on Device, measured in T BIT
T BIT
Bit time, measured in s
t CYC
Cycle time on F-sequence level, measured in s
t DF
Fall time, measured in s
T DMT
Delay time while establishing Master port communication, measured in T BIT
t DR
Rise time, measured in s
T DSIO
Delay time on Device for transition to SIO mode following wake-up request, measured in s
T DWU
Wake-up retry delay, measured in s
t F-sequence
F-sequence duration, measured in T BIT
t idle
Idle time between two F-sequences, measured in s
tH
Detection time for high level, measured in s
tL
Detection time for low level, measured in s
t ND
Noise suppression time, measured in s
T OFS
Temporal offset for process data processing on the Device with reference to start of cycle, measured in s
T RDL
Wake-up readiness following power ON, measured in s
T REN
Receive enable, measured in s
[IEC 61131-2]
Working Draft
– 26 –
61131-9/WD V0.5 IEC
T SD
Device detect time, measured in s
T WU
Pulse duration of wake-up request, measured in s
UART
Universal asynchronous receiver transmitter
UML
Unified modelling language
V+
Voltage at L+
V0
Voltage at L-
VD-
Voltage drop on the line between the L- connections on Master and Device, measured in V
VD+
Voltage drop on the line between the L+ connections on Master and Device, measured in V
VDQ
Voltage drop on the line between the C/Q connections on Master and Device, measured in V
VHYS
Hysteresis of receiver threshold voltage, measured in V
VI
Input voltage at connection C/Q with reference to V0, measured in V
VIH
Input voltage range at connection C/Q for high signal, measured in V
VIL
Input voltage range at connection C/Q for low signal, measured in V
VRQ
Residual voltage on driver in saturated operating status ON, measured in V
VRQH
Residual voltage on high-side driver in operating status ON, measured in V
VRQL
Residual voltage on low-side driver in saturated operating status ON, measured in V
VTH
Threshold voltage of receiver with reference to V0, measured in V
VTHH
Threshold voltage of receiver for safe detection of a high signal, measured in V
VTHL
Threshold voltage of receiver for safe detection of a low signal, measured in V
WURQ
Wake-up request pulse
235 236
3.3
237
3.3.1
238 239
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.
240
3.3.2
241 242 243 244
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.
245 246 247
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
Conventions General
Service parameters
248
1) parameter name,
249
2) request primitive (.req),
250
3) indication primitive (.ind),
251
4) response primitive (.rsp), and
252
5) confirmation primitive (.cnf).
61131-9/WD V0.5 IEC 253 254 255
– 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.
256
M Parameter is mandatory for the primitive.
257 258 259
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.
260 261
C Parameter is conditional upon other parameters or upon the environment of the service user.
262
–
Parameter is never present.
263
S
Parameter is a selected item.
264
Some entries are further qualified by items in brackets. These may be
265 266
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;
267 268
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.
269
3.3.3
270
The procedures are defined in terms of
271 272
the interactions between application entities through the exchange of protocol data units, and
273 274
the interactions between a communication layer service provider and a communication layer service consumer in the same system through the invocation of service primitives.
275 276
These procedures are applicable to instances of communication between systems which support time-constrained communications services within the communication layers.
277
3.3.4
278 279
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.
Service procedures
Service attributes
280
I
Initiator of a service (towards the layer above)
281
R Receiver (responder) of a service (from the layer above)
282
3.3.5
283 284
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).
Memory and transmission octet order
Working Draft
61131-9/WD V0.5 IEC
– 28 – Memory n+4 n+3 n+2 n+1
LSO
n
MSO
Transmission
MSO 215
0
285 286
LSO 20
Transmission time
t
Figure 1 – Memory and transmission octet order
287
3.3.6
288 289 290
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].
291 292 293 294 295 296
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)".
297
Asynchronously received service calls are not modelled in detail within state diagrams.
298
4
299
4.1
300 301 302 303 304 305 306 307
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.
Behavioral descriptions
Overview of SDCI (IO-Link TM 3 ) Purpose of technology
————————— 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 –
L+
1 2
C/Q
4 3
SIO
SDCI
4,8 / 38,4 / 230,4 kbit/s
Working Draft Pin
Signal
Definition
Standard
1
L+
24 V
IEC 61131-2
2
I/Q
Not connected, DI, or DO
IEC 61131-2
3
L-
0V
IEC 61131-2
4
Q
"Switching signal" DI, DO (SIO)
IEC 61131-2
C
"Coded switching" (SDCI)
IEC 61131-9
LIEC 60947-5-2
308 309
Figure 2 – SDCI compatibility with IEC 61131-2
310
4.2
311
Figure 3 shows the domain of the SDCI technology within the automation hierarchy.
Positioning within the automation hierarchy
PLC PLC // Host Host
Parameter server
Fieldbus Fieldbus controller controller Fieldbus integration
Fieldbus Fieldbus interface interface Gateway Gateway application application Data storage
Master Master SDCI
312
Port 1
Port 2
Engineering: configuration, parameterization, diagnosis, identification & maintenance
Port n
Device Device
Device Device
Device Device
Application Application
Application Application
Application Application
Device description
313
Figure 3 – Domain of the SDCI technology within the automation hierarchy
314 315 316
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.
317 318 319 320
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").
321 322 323 324 325 326 327 328
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
61131-9/WD V0.5 IEC
– 30 –
329 330
Configuration and parameterization of Devices is supported through an XML-based device description [3], which is not part of this document.
331
4.3
332 333 334 335 336 337
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.
338
4.4
339
The generic Device model is shown in Figure 4 and explained in the following section.
Wiring, connectors and power
Communication features of SDCI
Process data
0...32 octets in
Parameter and commands 232 0xFFFF Index 0...65535, 232 octets/index maximum
0
0xFF
Event buffer (diagnosis) Subindex 1...255 selective
0...32 octets out
Subindex 0 entire record ... 232
...
0x00 0
Direct parameter page 1+2
0x00
340
0...32 octets
15
0
341
Figure 4 – Generic Device model for SDCI (Master's view)
342 343 344 345 346 347 348 349 350 351
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).
352 353 354
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.
355 356 357
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
– 31 –
Working Draft
358 359 360 361
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).
362 363 364 365
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
Communication Channel
Transmission Type
Input, Input,Output Output Operation Operation
Process Process
Cyclic Cyclic (default) (default)
Valid, Valid, Invalid Invalid
Configuration/ Configuration/ maintenance maintenance
Direct Direct parameter parameter page page (Page (Page 11 or or2) 2)
Page Page
Parameter Parameter (Index (Index>1) >1)
ISDU ISDU On-request On-request (acyclic) (acyclic)
Errors Errors Events Events
366
Warnings Warnings
Diagnosis Diagnosis
Notifications Notifications
367
Figure 5 – Relationship between nature of data and transmission types
368 369
The first octet of a Master message controls the data transfer direction (read/write) and the type of communication channel.
370 371 372 373 374 375
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).
376 377 378
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
61131-9/WD V0.5 IEC
– 32 –
Systemmanagement management System
Master applications
Read
Write
On-request data objects DL DL Port Port
Event n ... Event n+4 Event n+5
Output
...
...
Port Port
Application layer (AL)
Process data objects
DL DL
Acyclic communication channels (on-request)
Systemmanagement management System
Input
DL DL
Data link layer (DL)
Port Port
Physical layer (PL)
Cyclic communication channel (process data)
DL DL On-request data objects Read
Write
Event n ... Event n+4 Event n+5
Process data objects Input Output
Device Device technology technology
379 380
Figure 6 – Object transfer at the application layer level (AL)
381
4.5
382 383 384 385 386 387
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.
388 389 390
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.
391 392
It is also possible to start with SDCI communication and after parameterization intentionally switch to DI mode via a fallback command (11.8.5).
393 394 395 396 397
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).
398 399
The Master is responsible for the assembling and disassembling of all data from or to the Devices (see Clause 11).
400 401 402 403
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).
Role of a Master
61131-9/WD V0.5 IEC
– 33 –
Working Draft
404
4.6
405 406 407 408 409 410 411
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.
412
4.7
413 414 415 416 417
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.
418
4.8
419 420 421 422 423
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).
Engineering for SDCI
Mapping to fieldbuses
Document structure
Master CM
DS
ODE
Device DU
PDE
PM
AL SM
424
DS
ED
PDE
AL
DL
DL
DL
...
PL
PL
PL
...
SIO
SM
DL
SIO
PL
Medium
425
Figure 7 – Logical structure of Master and Device
426 427 428 429
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.
430 431 432 433 434
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.
435 436 437 438 439 440 441 442 443 444
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
61131-9/WD V0.5 IEC
– 34 –
445 446
Annex K provides contact details for organizations, which support the SDCI technology and offer help with design, conformity testing, device description and fieldbus integration.
447
5
448
5.1
449
5.1.1
450 451 452 453
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.
Physical Layer (PL) General Basics
L+ C/Q
Master
Device
L-
454 455
Figure 8 – Three wire connection system PHY-3W
456 457
NOTE Binary sensors compliant with IEC 60947-5-2 are compatible with the PHY-3W interface (including from a power consumption point of view).
458 459
Support of PHY-3W is mandatory for Master. Ports with this characteristic are called port class A.
460 461
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).
462 463
Five wire connections (port class B) are specified for Devices requiring additional power from an independant 24 V power supply (see 5.5.1).
464
5.1.2
465 466 467
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.
Topology
Master Ports
1
2
3
...
n
SDCI links
Devices
468 469
1
2
3
n
Figure 9 – Topology of SDCI
470
5.2
471
5.2.1
472
Figure 10 presents an overview of the Master's physical layer and its services.
Physical layer services Overview
61131-9/WD V0.5 IEC
– 35 –
System Management Port x handler
PL-Mode.req
Working Draft
Data Link Layer Master DL-mode handler
Frame handler
PL-WakeUp.req
PL-Transfer.req
DI / DO
PL-Transfer.ind
Mode switch Inactive
Wake-up
Coded switching
Switching signal
Physical Layer (port)
473 474
Figure 10 – Physical layer (Master)
475 476 477 478
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.
479 480 481 482 483 484
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).
485
Figure 11 presents an overview of the Device's physical layer and its services. System Management Line handler
PL-Mode.req
Data Link Layer Device DL-mode handler
PL-WakeUp.ind
Frame handler
PL-Transfer.ind
DI / DO
PL-Transfer.req
Mode switch Wake-up
486
Coded switching
Switching signal
Physical Layer
487
Figure 11 – Physical layer (Device)
488 489 490 491 492 493
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.
494 495
A special MasterCommand (fallback) sent via SDCI causes the Device to switch back to SIO mode.
496 497 498 499
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.
500
Working Draft 501
61131-9/WD V0.5 IEC
– 36 –
Table 1 – Service assignments of Master and Device Service name
Master
Device
PL-Mode
R
R
PL-WakeUp
R
I
PL-Transfer
I/R
R/I
Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service
502 503
5.2.2
504
5.2.2.1
505 506
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.
507
Table 2 – PL_Mode
PL services PL_Mode
Parameter name
.req
Argument
M
TargetMode
508 509 510
M
Argument The service specific parameters of the service request are transmitted in the argument.
511 512
TargetMode This parameter specifies the requested operation mode
513
Permitted values : INACTIVE, DI, DO, COM1, COM2, COM3
514 515
5.2.2.2
516 517
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.
518
5.2.2.3
519 520
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.
521
Table 3 – PL_Transfer
PL_WakeUp
PL_Transfer
Parameter name
.req
ind.
Argument Data Status
522 523 524
M
M M
Argument The service specific parameters of the service request are transmitted in the argument.
525 526
Data This parameter specifies the data value which is transferred over the SDCI interface.
527
Permitted values: 0…255
61131-9/WD V0.5 IEC
– 37 –
Working Draft
528 529
Status This parameter specifies supplementary information on the transfer status.
530
Permitted values: PARITY_ERROR, FRAMING_ERROR, OVERRUN
531 532
5.3
533
5.3.1
534 535 536 537
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.
538
5.3.2
539
5.3.2.1
540 541 542 543 544
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).
545 546 547
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).
Transmitter/Receiver Description method
Electrical requirements General
On/ Off
548
VRQ IQ IQPK
Overload
549
Figure 12 – Line driver reference schematics
550 551 552 553
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
H/L
VTH VHYS
554
V0
555
Figure 13 – Receiver reference schematics
556 557
Figure 14 shows the reference schematics for the interconnection of Master and Device for PHY-3W.
Working Draft
61131-9/WD V0.5 IEC
– 38 – Device
Line
V+D
Master
VD+L
L+
V+M
L+ ISM
ISD VRQHD IQHD IQPKHD
On/ Off
On/ Off
VRQHM IQHM IQPKHM
OVD
C/Q
H/L
VDQL
C/Q
H/L
VSD optional 1)
VRQLD IQLD IQPKLD
VID
CQD
On/ Off
VIM
VSM
VRQLM IQLM IQPKLM
ILLM CQM
On/ Off
OVD
L-
V0D
558
L-
VD0L
V0M
Note 1) optional: low -side driver (push-pull only)
559
Figure 14 – Master and Device reference schematics for PHY-3W
560 561 562 563
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
Master VD+L
V+D
V+M
VRQHM
VRQHD
VSD
VSM
VDQL
VID VIM VRQLD V0D
564
Output
Input
VD0L
VRQLM Input
565
Output
V0M
Figure 15 – Voltage level definitions
566
5.3.2.2
567 568
The voltage range and switching threshold definitions are the same for Master and Device. The definitions in Table 4 apply.
Receiver
61131-9/WD V0.5 IEC 569
– 39 –
Working Draft
Table 4 – Electric characteristics of a receiver Property
Designation
Minimum
Typical
Maximum
Unit
Remark
VTHH D,M
Input threshold 'H'
10,5
n/a
13
V
See NOTE 1
VTHL D,M
Input threshold 'L'
8
n/a
11,5
V
See NOTE 1
VHYS D,M
Hysteresis between input thresholds 'H' and 'L'
0
n/a
n/a
V
Shall not be negative
VIL D,M
Permissible voltage range 'L'
V0 D,M -1,0
n/a
n/a
V
With reference to relevant negative supply voltage
VIH D,M
Permissible voltage range 'H'
n/a
n/a
V+ D,M + 1,0
V
With reference to relevant positive supply voltage.
See NOTE 2
NOTE 1
Thresholds are compatible with the definitions of type 1 digital inputs in IEC 61131-2.
NOTE 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'
Threshold 'H'
VTHHMAX VTHLMAX VTHHMIN
Threshold 'L'
VTHLMIN
Voltage range 'L'
V0
572 573
Figure 16 – Switching thresholds
574
5.3.2.3
575
The definitions in Table 5 are valid for the electric characteristics of a Master port.
576
Master port
Table 5 – Electric characteristics of a Master port Property
Designation
Minimum
Typical
Maximum
Unit
Remark
VS M
Supply voltage for Devices
20
24
30
V
IS M
Supply current for Devices
200
n/a
n/a
mA
External supply required for > 200 mA
Current pulse capability for Devices
400
n/a
n/a
mA
Master supply current capability for a minimum of 50 ms at 18 V after power-on of the port supply
ISIR M
ILL M
Load or discharge current for 0 V < VI M < 5 V
See NOTE 1 0
n/a
15
mA
5
n/a
15
mA
Working Draft Property
61131-9/WD V0.5 IEC
– 40 – Designation
Minimum
Typical
Maximum
Unit
5 V < VI M < 15 V 15 V< VI M < 30 V
5
n/a
15
mA
Remark
VRQH M
Residual voltage 'H'
n/a
n/a
3
V
Voltage drop relating to V+ M at maximum driver current IQH M
VRQL M
Residual voltage 'L'
n/a
n/a
3
V
Voltage drop relating to V0 M at maximum driver current IQL M
DC driver current 'H'
100
n/a
n/a
mA
Output peak current 'H'
500
n/a
n/a
mA
DC driver current 'L'
100
n/a
n/a
mA
Output peak current 'L'
500
n/a
n/a
mA
Absolute value See NOTE 2
Input capacitance
n/a
n/a
1,0
nF
f=0 MHz to 4 MHz
IQH M IQPKH M IQL M IQPKL M CQ M NOTE 1
Currents are compatible with the definition of type 1 digital inputs in IEC 61131-2
NOTE 2
Wake-up request current (5.3.3.3).
Absolute value See NOTE 2
577 578
5.3.2.4
579
The definitions in Table 6 are valid for the electric characteristics of a Device.
Device
580
Table 6 – Electric characteristics of a Device Property VS D VS D
Designation
Minimum
Typical
Maximum
Unit
Supply voltage
18
24
30
V
Ripple
n/a
n/a
1,3
V pp
Remark
Peak-to-peak absolute value limits shall not be exceeded. f ripple = DC to 100 kHz
VRQH D
Residual voltage 'H'
n/a
n/a
3
V
Voltage drop compared with V+ D (IEC 60947-5-2)
VRQL D
Residual voltage 'L'
n/a
n/a
3
V
Voltage drop compared with V0 D
IQH D
DC driver current
50
n/a
minimum (IQPKL M )
mA
Minimum value due to fallback to digital input in accordance with IEC 61131-2, type 2
0
n/a
minimum (IQPKH M )
mA
Only for push-pull output stages
0
n/a
15
mA
Pull-down or residual current with deactivated output driver stages
0
n/a
1,0
nF
Effective capacitance between C/Q and L+ or L- of Device in receive state
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
61131-9/WD V0.5 IEC Property
– 41 –
Designation
Minimum
Working Draft
Typical
Maximum
Unit
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
5.3.3
583
5.3.3.1
584 585 586
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.
587 588
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-.
589 590
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.
Timing requirements Transmission method
Transmitted bit sequence
1st
2
3
4
5
6
7
8
9
20 lsb
Significance of information bits 0
b0
10
11th
27 msb b1
Start bit (ST)
b2
b3
b4
b5
b6
b7
P
1
Data octet Parity bit (even)
Key: lsb msb
591
least significant bit most significant bit
One stop bit (SP)
592
Figure 17 – Format of an SDCI UART frame
593 594
The definition of the UART frame format is based on ISO/IEC 1177:1985 and ISO/IEC 2022:1986.
595
5.3.3.2
596 597 598
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.
599 600
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.
601 602 603
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.
Transmission characteristics
Working Draft
61131-9/WD V0.5 IEC
– 42 – tH
tND
tND
tL
VIHD,M MAX V+D,M Detection 'H'
VTHHMAX
b)
VTHHMIN
VTHLMAX
VTHLMIN a)
Detection 'L'
V0D,M VILD,M MIN tDR
tDF TBIT
TBIT
a) no detection 'L' b) no detection 'H'
604 605
Figure 18 – Eye diagram for the 'H' and 'L' detection
606 607 608
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
Bit n=2
Bit n=3
Bit n=9
Stop Bit n=11
Bit n=10 TBIT
VTHH VTHL
(2-r)TBIT
609
(1-s)TBIT
(2-s)TBIT
(3-r)TBIT (3-s)TBIT
(10-r)TBIT
(11-r)TBIT
(10-s)TBIT
(11-s)TBIT
610
Figure 19 – Eye diagram for the correct detection of a UART frame
611 612 613 614 615 616
For every bit n in the bit sequence (n =1…11) 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.
617 618
This representation permits a variable weighting of the influence parameters "transmission rate accuracy", "bit-width distortion", and "slew rate" of the receiver.
619
Table 7 specifies the dynamic characteristics of the transmission.
620
61131-9/WD V0.5 IEC 621
– 43 –
Working Draft
Table 7 – Dynamic characteristics of the transmission Property
Designation
f DTR
transmission rate
T BIT
Bit time at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s
Δf DTRM
Master transmission rate accuracy at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s
Minimum
Typical
Maximum
Unit
n/a
4,8 38,4 230,4
n/a
kbit/s
Remark COM1 COM2 COM3
μs µs µs
208,33 26,04 4,34
-0,1 -0,1 -0,1
n/a n/a n/a
+0,1 +0,1 +0,1
% % %
Tolerance of the transmission rate of the Master T BIT /T BIT
r
Start of detection time within a bit with reference to the raising edge of the start bit
0,65
n/a
n/a
-
Calculated in each case from the end of a bit at a UART sampling rate of 8 (see NOTE)
s
End of detection time within a bit with reference to the raising edge of the start bit
n/a
n/a
0,22
-
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
T DR
T DF
t ND
Rise time
0
n/a
0,20
T BIT
at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s
0 0 0
n/a n/a n/a
41,7 5,2 869
μs μs ns
Fall time
0
n/a
0,20
T BIT
at 4,8 kbit/s at 38,4 kbit/s at 230,4 kbit/s
0 0 0
n/a n/a n/a
41,7 5,2 869
μs μs ns
n/a
n/a
1/16
T BIT
Permissible duration of a receive signal above/below the detection threshold without detection taking place
Noise suppression time
With reference to the bit time unit
tH
Detection time High
1/16
n/a
n/a
T BIT
Duration of a receive signal above the detection threshold for 'H' level
tL
Detection time Low
1/16
n/a
n/a
T BIT
Duration of a receive signal below the detection threshold for 'H' level
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
5.3.3.3
624
The wake-up feature initiates the changeover of a Device to a ready-to-receive state.
625
A service call (PL_WakeUp.req) from the DL initiates the wake up process (see 5.2.2.2).
626 627
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):
Wake-up current pulse
Working Draft
61131-9/WD V0.5 IEC
– 44 –
628 629 630
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.
631
b) Delay time of the Device until it is ready to receive.
632 633 634
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
Wake-up request
V a)
Receiver enabled
b)
Q = low
undefined
High impedance, low level
Q = high
undefined
High impedance, low level
T
TWU TREN
635 636
Figure 20 – Wake-up request
637 638
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 .
639
Table 8 – Wake-up request characteristics Property IQWU
Designation Amplitude of Master’s wake-up current pulse
Minimum
Typical
Maximum
Unit
Remark
IQPKLM or
n/a
n/a
mA
Current pulse followed by switching status of Device
IQPKHM
TWU
Duration of Master's wake-up current pulse
75
n/a
85
μs
Master property
TREN
Receive enable delay
n/a
n/a
500
μs
Device property
640 641
5.4
642
5.4.1
643 644
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.
Power supply Power-on requirements
61131-9/WD V0.5 IEC
– 45 –
Working Draft
VS
VSD,M min
Ready for wake-up
t
TRDL
645 646
Figure 21 – Power-on timing
647 648
Upon power-on it is mandatory for a Device to reach the wake-up ready state within the time limits defined in Table 9.
649
Table 9 – Power-on timing Property T RDL
NOTE
Designation Wake-up readiness following power-on
Minimum n/a
Typical n/a
Maximum 300
Unit ms
Remark Device ramp-up time until it is ready for wake-up signal detection See NOTE
Equivalent to the time delay before availability in IEC 60947-5-2.
650 651
5.4.2
652 653 654
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.
655
5.4.3
656 657
The Device may be separately and additionally supplied with power. The communication section of the Device (PHY-3W) shall always be Master powered.
658
5.5
659
5.5.1
660 661 662
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).
663
NOTE
664 665
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.
666 667 668 669
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.
Master powered Device
External power supply
Medium Connector
Port class A and port class B are not compatible.
Working Draft
61131-9/WD V0.5 IEC
– 46 –
670
Table 10 – Pin assignments Pin
Signal
1
L+
2
I/Q P24
3
L-
4 5
Designation Power supply (+)
Remark See Table 6
NC/DI/DO (port class A) Option P24 (port class B) Option Option Option
1: 2: 3: 4:
NC (not connected) DI DI, then configured DO Extra power supply for power Devices (port class B)
Power supply (-)
See Table 6
C/Q
SIO/SDCI
Standard I/O mode or SDCI
NC N24
NC (port class A) N24 (port class B)
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
Class A
4
2
3
Class B
Class A
2
2
4
1
1
Male (Device)
3
3 1
2
1
3
5 4
4
M5 3
Female (Master)
M8 4
4
M12-4
2
2
2
1
1
3
3 2
1
3
1
5
5 4
M5
672
M12-5
M8
M12-5
4
M12-5
M12 connectors are "A"-coded according to IEC 61076-2-101
673
Figure 22 – Pin layout front view
674 675
Figure 23 shows the layout of the two port classes A and B. Class B ports shall be marked unambiguously due to the incompatibilities.
676 677
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
– 47 –
Working Draft
Port Class A (M12) 2 I/Q 1
PIN PIN 2: 2: Power 1
4
SDCI power supply
C/Q 3
PIN PIN 5: 5: PIN PIN 4: 4:
5
Option Option 1: 1: NC NC (not (not connected) connected) Option Option 2: 2: DI DI Option Option 3: 3: DI DI configured configured DO DO NC NC DI; DI; SDCI/SIO; SDCI/SIO; DO DO
Port Class B (M12) Protection
2 1
Power 2
P24 (Act)
Power 1
4
SDCI power supply
C/Q 3
Power Device power supply
5
PIN PIN 2: 2:
P24 P24 (extra (extra power power supply supply for for power power Devices, Devices, current current is is manufacturer manufacturer dependent) dependent)
PIN PIN 5: 5: PIN PIN 4: 4:
N24 N24 (0 (0 V, V, power power Device) Device) DI; DI; SDCI/SIO; SDCI/SIO; DO DO
N24 (Act)
678 679
Figure 23 – Class A and B port definitions
680
5.5.2
681 682 683 684
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.
685
Table 11 – Cable characteristics
Cable
Property
Minimum
Typical
Maximum
Unit
Length
0
n/a
20
m
Overall loop resistance RLeff
n/a
n/a
6,0
Ω
Effective line capacitance CLeff
n/a
n/a
3,0
nF ( 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
TYPE_1_1
TYPE_1_2
TYPE_1_V
TYPE_2_1
TYPE_2_2
TYPE_2_3
TYPE_2_4
TYPE_2_5
TYPE_2_6
TYPE_2_V
FC
FC
FC
FC
FC
FC
FC
FC
FC
FC
CKT
CKT
CKT
CKT
CKT
CKT
CKT
CKT
CKT
CKT
WR OD
CKS
PD0
PD1
OD0
OD1
CKS
CKS
OD0
OD
OD
PD
PD0
PD
PD0
PD0
ODn
PD
CKS
PD0
PD1
OD
CKS
CKS
PD1
OD
OD
PD
PD1
OD
PDn-1
1295 1296
CKS
CKS
CKS
PD0
OD0
PD1
CKS
ODm-1
PD0
PDk-1
CKS
Figure 36 – Overview of F-sequence types
1297
7.3.3.3
1298 1299 1300 1301
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.
1302 1303 1304
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.
MasterCycleTime constraints
Working Draft
61131-9/WD V0.5 IEC
– 74 –
1305 1306 1307
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).
1308 1309
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.
1310
7.3.3.4
1311 1312
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.
1313 1314 1315 1316 1317
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.
1318 1319
The state "StartupPreop_2" is the checkpoint for all On-request Data activities such as ISDUs, parameters, commands, and events.
Master state machine of the frame handler
FH_Config_OPERATE/ T1
FH_Config_INACTIVE/ T27
Operate_8
tm(Tcyc)/ T16
FH_Config_INACTIVE/ T26
FH_Config_OPERATE/ T15 StartupPreop_2
FH_Config_COMREQUEST/ T2 tm(Tinitcyc)/ T7
SetOD_7
GetOD_3
tm(TF-sequence)/ T4 AwaitReply_1
[Ready]/ T17
[ReceivedOK]/ T3 [ReadyToSend]/ T8
GetOD_10
[ReadyToSend]/ T18
[ReceivedOK]/ T12 enex_2
Response_11
enex_3 enex_4 [ReceivedOK]/ T22
Inactive_0
FH_Config_STARTUP/ T6
[Ready]/ T14
GetPD_9
/Initialization
[ReceivedNotOK]/ T5
Response_4
[Retry = MaxRetry]/ T13 enex_1
[Retry = MaxRetry]/ T23
SetPD_14
[Ready]/ T24 [NoError]/ T25
SetOD_15
1320 1321
Figure 37 – Master state machine of the frame handler
1322 1323
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
– 75 –
Working Draft
1324 1325
from the Process Data handler and optionally On-request Data acquired from the on-request data handler.
1326
Figure 38 shows the submachine of state "Response 4". Response_4
/T8 enex_2
AwaitReply_5
/T12
tm(TF-sequence)/ T9
enex_1 Errorhandling_6 /T13
[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
tm(TF-sequence)/ T19
AwaitReply_12
ErrorHandling_13
enex_3
[ReceivedNotOK]/ T20
/T22
tm(Tcyc)[Retry < MaxRetry]/ T21 (Re-send)
enex_4
1330 1331 1332
/T23
Figure 39 – Submachine "Response 11" of the frame handler Table 38 shows the state transition tables of the Master frame handler.
1333 1334
Table 38 – State transition table of the Master frame handler STATE NAME
STATE DESCRIPTION
Inactive_0
Waiting on ComRequest or Startup
AwaitReply_1
Waiting on ComRequest response
StartupPreop_2
Checkpoint: Wait until T initcyc from last cycle elapsed
GetOD_3
Collect on-request data from on-request handler (ISDU, parameter/command, event)
Response_4
Device response and error check
SM: AwaitReply_5
Waiting on Device response
SM: ErrorHandling_6
Error check and reaction (retry, etc.)
SetOD_7
Distribute on-request data
Operate_8
Checkpoint: Wait until T cyc from last cycle elapsed
GetPD_9
Collect process data from PD handler
GetOD_10
Collect on-request data from on-request handler (ISDU, parameter/command, event)
Working Draft STATE NAME
1335
STATE DESCRIPTION
Response_11
Device response and error check
SM: AwaitReply_12
Waiting on Device response
SM: ErrorHandling_13
Error check and reaction (Retry, etc.)
SetPD_14
Distribute process data
SetOD_15
Distribute on-request data
TRANSITION
1336
61131-9/WD V0.5 IEC
– 76 –
SOURCE STATE
TARGET STATE
T1
0
8
-
T2
0
1
Read octet 3 (MinCycleTime) in direct parameter page with F-sequence TYPE_0
T3
1
0
Return value of MinCycleTime
T4
1
0
Timeout: negative response
T5
1
0
Other error: negative response
T6
0
2
-
T7
2
3
Cast ComTrig to on-request handler
T8
3
4
Create message from CMD.req and send it to Device. Start F-sequence LengthTimer
T9
5
6
-
T10
5
6
-
T11
6
5
Re-send message
T12
4
7
-
T13
4
0
Error indication: FHInfo.ind(COMMLOST)
T14
7
2
-
T15
2
8
-
T16
8
9
Cast PDTrig to process data handler
T17
9
10
Cast ComTrig to on-request handler
T18
10
11
Create message from CMD.req and PD.req and send it to Device
T19
12
13
-
T20
12
13
-
T21
13
12
Re-send message
T22
11
14
-
T23
11
0
Error indication: FHInfo.ind(COMMLOST)
T24
14
15
-
T25
15
8
-
T26
2
0
Stop communication
T27
8
0
Stop communication
INTERNAL ITEMS Retry
ACTION
TYPE Variable
DEFINITION Retry counter
MaxRetry
Number
MaxRetry = 2, see Table 91
ReceivedOK
Bool
Error checking of Device message successful
ReceivedNotOK
Bool
Error checking of Device message not successful due to detected errors
F-sequence LengthTimer
Timer
Measurement of Device response time
t F-sequence
Time
See equation (A.6)
t cyc
Time
See equation (A.7)
61131-9/WD V0.5 IEC INTERNAL ITEMS
– 77 –
Working Draft
TYPE
t initcyc
DEFINITION
Time
See A.2.6
1337 1338
7.3.3.5
1339
Figure 40 shows the Device state machine of the frame handler.
Device state machine of the frame handler
tm(ComTimeout)/ T9
[Ready]/ T6 (send)
FH_Config_ACTIVE/ T1
Idle_1
CreateMessage_4
Inactive_0
FH_Config_INACTIVE/ T10
[Error]/ T7
[No error]/ T5
/Initialization
[FirstOctet]/ T2
tm(MessageTimeout)/ T8
GetMessage_2
CheckMessage_3
[NextOctet]/ T3
[Completed]/ T4
1340 1341 1342
Figure 40 – Device state machine of the frame handler Table 39 shows the state transition tables of the Device frame handler.
1343
Table 39 – State transition tables of the Device frame handler STATE NAME
1344
1345
STATE DESCRIPTION
Inactive_0
Waiting for activation
Idle_1
Waiting on first octet of Master message
GetMessage_2
Receive Master message octet by octet
CheckMessage_3
Check F-sequence type, checksum, length, consistency
CreateMessage_4
Create message from CMD.rsp, PD.rsp, EventFlag State and PD Valid State
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
2
Start message timer
T3
2
2
Check message length
T4
2
3
Stop message timer
T5
3
4
Create CMD.ind and/or PD.ind
T6
4
1
Create PL_Transfer.rsp
T7
3
1
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.
T8
2
1
-
T9
1
1
Create FHInfo.ind(COMMLOST). Actuators shall observe this information and take corresponding actions.
T10
1
0
-
INTERNAL ITEMS MessageTimeout
TYPE Time
ACTION
DEFINITION Observation of the message transmission time for the purpose of resynchronization of communication ("first octet detection")
Working Draft
61131-9/WD V0.5 IEC
– 78 –
INTERNAL ITEMS
TYPE
DEFINITION
ComTimeout
Time
Observation of the Device specific maximum cycle time. This is important especially for actuators. See 10.2.
MessageTimeout
Time
Maximum "length" of Master message of the actual F-sequence type
FirstOctet
Service
PL_Transfer.ind with the first octet of the Master message
NextOctet
Service
PL_Transfer.ind with subsequent octets of the Master message
Error
Bool
One of the possible errors detected: ILLEGAL_FRAME_TYPE, CHECKSUM_MISMATCH
1346 1347
7.3.4
1348
7.3.4.1
1349 1350 1351 1352
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.
1353 1354 1355
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).
1356
7.3.4.2
1357 1358 1359 1360 1361
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.
Process data handler General
Interleave mode
Process data cycle n
Process data cycle n+1 t (time)
1362 1363
FC
CKT
PD0
PD1
FC
CKT
OD0
OD1
FC
CKT
PD2
PD3
FC
CKT
OD0
OD1
FC
CKT
PDx-1
PDx
FC
CKT
OD0
OD1
FC
CKT
PD0
PD1
FC
CKT
OD0
OD1
Cycle time
Not recommended for new developments of Devices
Figure 41 – Interleave mode for the segmented transmission of process data
1364
7.3.4.3
1365
Figure 42 shows the Master state machine of the process data handler.
Master state machine of the process data handler
61131-9/WD V0.5 IEC
– 79 –
Working Draft
PDComTrig/ T1
/initialization Inactive_0
PD_Config_INACTIVE/ T11
PD_Config_INACTIVE/ T9
PD_Config_SINGLE/ T2
PD_Config_INACTIVE/ T10
PD_Config_INTERLEAVE/ T4
PDInInterleave_2
PDSingle_1
[Input Data Completed]/ T6
PDOutInterleave_3
[Output Data Completed]/ T8 PDComTrig/ T3
1366 1367 1368
Figure 42 – Master state machine of the process data handler Table 40 shows the state transition tables of the Master process data handler.
1369
Table 40 – State transition tables of the Master process data handler STATE NAME
1370
1371
PDComTrig/ T7
PDComTrig/ T5
STATE DESCRIPTION
Inactive_0
Waiting for activation
PDSingle_1
Process data communication via single F-sequences
PDInInterleave_2
Input ProcessDataIn interleave mode
PDOutInterleave_3
Output ProcessDataOut interleave mode
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
0
Create PD.req with no process data
T2
0
1
-
T3
1
1
Create DL_PDInputTransport.ind, DL_PDCycle.ind and PD.req with input and output data
T4
0
2
-
T5
2
2
Create PD.req for input data
T6
2
3
Create DL_PDInputTransport.ind (see 7.2.1.11)
T7
3
3
Create PD.req with output data
T8
3
2
Create DL_PDCycle.ind (see 7.2.1.12)
T9
1
0
-
T10
2
0
-
T11
3
0
-
INTERNAL ITEMS
TYPE
ACTION
DEFINITION
None
1372 1373
7.3.4.4
1374
Figure 43 shows the Device state machine of the process data handler.
Device state machine of the process data handler
Working Draft
61131-9/WD V0.5 IEC
– 80 –
/initialization PDTrig/ T1
Inactive_0
PD_Config_ACTIVE/ T2 PDSingle_1
PD_Config_INACTIVE/ T7 PDTrig/ T3
HandlePD_2
[PD incomplete]/ T4 [New output complete]/ T5 [Cycle complete]/ T6
1375 1376 1377
Figure 43 – Device state machine of the process data handler Table 41 shows the state transition tables of the Device process data handler.
1378
Table 41 – State transition tables of the Device process data handler STATE NAME
1379
STATE DESCRIPTION
Inactive_0
Waiting on activation
PDActive_1
Handler active and waiting on next message
HandlePD_2
Check process data for completeness
TRANSITION
1380
SOURCE STATE
TARGET STATE
T1
0
0
Ignore Process Data
T2
0
1
-
T3
1
2
Create PD.ind with Process Data (see 7.2.2.3)
T4
2
1
-
T5
2
1
Create DL_PDOutputTransport.ind (see 7.2.1.9)
T6
2
1
Create DL_PDCycle.ind (see 7.2.1.12)
T7
1
0
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
None
1381 1382
7.3.5
1383
7.3.5.1
1384 1385 1386 1387
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.
1388 1389
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.
On-request data handler General for Master and Device
61131-9/WD V0.5 IEC
– 81 –
Working Draft
1390 1391 1392
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.
1393 1394 1395
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.
1396 1397
In case of a valid access, the corresponding service, control or event state machine is addressed on the relevant communication channel.
1398 1399 1400 1401
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.
1402 1403
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.
1404 1405
NOTE Cmd.ind (R, ISDU, FlowCTRL = IDLE) is the default message if there are no on-request data pending for transmission.
1406
7.3.5.2
1407 1408 1409
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).
Master state machine of the on-request data handler
/initialization Inactive_0
OH_Config_ACTIVE/ T1
OH_Config_INACTIVE/ T16
ComTrig/ T12
Startup_1
OH_Config_STARTUP/ T15
OH_Config_STARTUP/ T14 [Startup completed]/ T2
OH_Config_STARTUP/ T13
ComTrig/ T11 Service_2
[Done & No EventActive]/ T4 Command_3
ComTrig/ T9
DL_Control/ T3 DL_Control/ T7
[Done & EventActive]/ T8
EventFlag/ T5
[Done]/ T6 Event_4
ComTrig/ T10
1410 1411
Figure 44 – Master state machine of the on-request data handler
Working Draft
61131-9/WD V0.5 IEC
– 82 –
1412 1413
This is performed through one of the ControlComTrig, EventComTrig or ServiceComTrig services.
1414
Table 42 shows the state transition tables of the Master process data handler.
1415
Table 42 – State transition tables of the Master on-request data handler STATE NAME
1416
Inactive_0
Waiting on activation
Startup_1
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).
Service_2
Default state of the on-request handler (lowest priority)
Command_3
State to control the Device via commands with highest priority
Event_4
State to convey event information (errors, warnings, notifications) with higher priority
TRANSITION
1417
STATE DESCRIPTION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
2
-
T3
2
3
-
T4
3
2
-
T5
2
4
EventActive = TRUE
T6
4
2
EventActive = FALSE
T7
4
3
-
T8
3
4
-
T9
3
3
Cast ControlComTrig.ind (Figure 49)
T10
4
4
Cast EventComTrig.ind (Figure 51)
T11
2
2
Cast ISDUComTrig.ind (Figure 47)
T12
1
1
Read or write direct parameter page via CMD.req
T13
2
1
-
T14
3
1
-
T15
4
1
-
T16
0
4
-
INTERNAL ITEMS EventActive
TYPE
ACTION
DEFINITION Flag to indicate return direction after interruption of event processing by a high priority command request
1418 1419
7.3.5.3
1420
Figure 45 shows the Device state machine of the on-request data handler.
Device state machine of the on-request data handler
61131-9/WD V0.5 IEC
– 83 –
Working Draft
EventRequest/ T5 CommandRequest/ T2
/initialization
OH_Config_ACTIVE/ T1
Idle_1
Inactive_0
OH_Config_INACTIVE/ T6
ParameterRequest/ T3
SPDURequest/ T4
1421 1422
Figure 45 – Device state machine of the on-request data handler
1423
Table 43 shows the state transition tables of the Device on-request data handler.
1424
Table 43 – State transition tables of the Device on-request data handler STATE NAME
1425
Inactive_0
Waiting on activation
Idle_1
Waiting on messages with on-request data. Decomposition and analysis.
TRANSITION
1426
STATE DESCRIPTION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
1
Trigger command handler
T3
1
1
Trigger service handler (direct parameter page). If DL-Mode = STARTUP then cast DL_Read / DL_Write, otherwise cast DL_ReadParam / DL_WriteParam
T4
1
1
Trigger service handler (ISDU)
T5
1
1
Trigger event handler
T6
1
0
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
CommandRequest
Service
CMD.ind(W, PARAMETER, 0, Command)
ParameterRequest
Service
CMD.ind(R/W, PARAMETER, 0, Data)
ISDURequest
Service
CMD.ind(R/W, ISDU, FlowCtrl, Data)
EventRequest
Service
CMD.ind(R/W, EVENT, n, Data)
1427 1428
7.3.6
1429
7.3.6.1
1430 1431 1432
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.
1433 1434
The ISDU allows accessing data objects (parameters and commands) to be transmitted (Figure 4). The data objects shall be addressed by the “Index” element.
Service handler Indexed Service Data Unit (ISDU)
Working Draft
61131-9/WD V0.5 IEC
– 84 – Service
Length
ExtLength Index Subindex Data 1 ... Data n CHKPDU = Checksum
1435 1436
Figure 46 – Structure of the ISDU
1437
7.3.6.2
1438 1439 1440 1441
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 Device’s response via the same channel.
1442 1443 1444 1445 1446
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.
1447
Table 44 – FlowCTRL definitions
Transmission of ISDUs
FlowCTRL 0x00 to 0x0F
Definition COUNT 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
– 85 –
Working Draft
1448
7.3.6.3
1449
Figure 47 shows the Master state machine of the service handler.
Master state machine of the service handler
/Initialization Inactive_0
SH_Config_INACTIVE/ T16
SH_Config_ACTIVE/ T1 ISDUComTrig[ ParaRequest]/ T13
ISDUComTrig[ DL_ISDUTransport]/ T2
Idle_1
ISDURequest_2 [Data written]/ T4
ISDUComTrig/ T14
DL_Mode_COMLOSS/ T12
ISDUComTrig/ T3
ISDUComTrig/ T11
ISDUComTrig/ T5
[Error]/ T9
ISDUError_4
ISDUWait_3
SH_Config_STOP/ T15 [Error]/ T10 ISDUComTrig[ Transmission completed]/ T8
[ResponseStart]/ T6
ISDUResponse_5 ISDUComTrig/ T7
1450 1451 1452
Figure 47 – Master state machine of the service handler Table 45 shows the state transition tables of the Master service handler.
1453
Table 45 – State transition tables of the Master service handler STATE NAME
1454
STATE DESCRIPTION
Inactive_0
Waiting on activation
Idle_1
Waiting on transmission of next on-request data
ISDURequest_2
Transmission of ISDU request data
ISDUWait_3
Waiting on response from Device. Observe ISDUTimer
ISDUError_4
Error handling after detected errors
ISDUResponse_5
Get response data from Device
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
2
Cast CMD.req with ISDU write start condition [CMD.req (W, ISDU, flowCtrl = START, data)]
T3
2
2
Cast CMD.req with ISDU data write and FlowCTRL under conditions of Table 44
T4
2
3
Start ISDUTimer
T5
3
3
Cast CMD.req with ISDU read start condition [CMD.req (R, ISDU, flowCtrl = START)]
T6
3
5
Stop ISDUTimer
T7
5
5
Cast CMD.req with ISDU data read and FlowCTRL under conditions of
ACTION
Working Draft TRANSITION
61131-9/WD V0.5 IEC
– 86 –
SOURCE STATE
TARGET STATE
ACTION Table 44
1455
T8
5
1
Cast positive DL_ ISDUTransport confirmation
T9
3
4
-
T10
5
4
-
T11
4
1
Cast CMD.req with ISDU abortion [CMD.req (R, ISDU, flowCtrl = ABORT)]. Cast negative DL_ ISDUTransport confirmation
T12
2
4
-
T13
1
1
Cast DL_CMD.req with appropriate data, cast positive DL_Read/WritePara confirmation
T14
1
1
Cast CMD.req with idle message [CMD.req (R, ISDU, flowCtrl = IDLE)]
T15
4
1
-
T16
1
0
-
INTERNAL ITEMS
TYPE
DEFINITION
ISDUTimer
Variable
Measurement of Device response time (watchdog, Table 91)
ResponseStart
Service
CMD.cnf(data ISDU_BUSY)
ParaRequest
Service
DL_Read or DL_Write
Error
Variable
Any detectable error within the ISDU transmission or DL_SDPUAbort requests, or any violation of the ISDU acknowledgement time (Table 91)
1456 1457
7.3.6.4
1458
Figure 48 shows the Master state machine of the service handler.
Device state machine of the service handler
ISDUWrite/ T3
/Initialization
Inactive_0
SH_Config_ACTIVE/ T1
ISDUIdle_1
ISDUStart/ T2
SH_Config_INACTIVE/ T12
ISDURequest_2
ISDUAbort/ T9
[ISDUSendComplete]/ T8
[ISDURecComplete]/ T4
ISDUAbort/ T10
ISDUAbort/ T11 ISDUResponse_4
ISDUWait_3 ISDURespStart/ T6
ISDURead/ T7
ISDURead/ T5
1459 1460 1461
Figure 48 – Device state machine of the service handler Table 46 shows the state transition tables of the Device service handler.
1462
Table 46 – State transition tables of the Device service handler STATE NAME
STATE DESCRIPTION
Inactive_0
Waiting on activation
ISDUIdle_1
Waiting on next ISDU transmission
ISDURequest_2
Reception of ISDU request
61131-9/WD V0.5 IEC
– 87 –
STATE NAME
1463
1464
Working Draft
STATE DESCRIPTION
ISDUWait_3
Waiting on data from application layer to transmit (see DL_ISDUTransport)
ISDUResponse_4
Transmission of ISDU response data
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
2
Start receiving of ISDU request data
T3
2
2
Receive ISDU request data
T4
2
3
Cast DL_ ISDUTransport.ind to application layer (see DL_ ISDUTransport)
T5
3
3
Cast CMD.rsp with "busy" indication (Table A.14)
T6
3
4
-
T7
4
4
Cast CMD.rsp with ISDU response data
T8
4
1
-
T9
2
1
-
T10
3
1
Cast DL_ ISDUAbort
T11
4
1
Cast DL_ ISDUAbort
T12
1
0
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
ISDUStart
Service
CMD.ind(W, ISDU, Start, Data)
ISDUWrite
Service
CMD.ind(W, ISDU, FlowCtrl, Data)
ISDURecComplete
Service
CMD.ind(R, ISDU, Start, ...)
ISDURespStart
Service
DL_ ISDUTransport.rsp()
ISDURead
Service
CMD.ind(R, ISDU, Start or FlowCtrl, ...)
ISDUSendComplete
Service
CMD.ind(R, ISDU, IDLE, ...)
ISDUAbort
Service
CMD.ind(R/W, ISDU, Abort, ...)
1465 1466
7.3.7
1467
7.3.7.1
1468 1469 1470
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.
1471
Table 47 – Control codes
Command handler General
Control code
MasterCommand
Description
PDOutValid
ProcessDataOutputOperate
Process output data valid
PDOutInvalid
DeviceOperate
Process output data invalid or missing
1472 1473
7.3.7.2
1474
Figure 49 shows the Master state machine of the command handler.
Master state machine of the command handler
Working Draft
61131-9/WD V0.5 IEC
– 88 –
/Initialization Inactive_0
CH_Config_ACTIVE/ T1 DL_Control_PDVALID/ T2
CH_Config_INACTIVE/ T6
Idle_1
DL_Control_PDINVALID/ T3
DL_Write_MasterCmd/ T4
MasterCommand_2
ControlComTrig/ T5
1475 1476 1477
Figure 49 – Master state machine of the command handler Table 48 shows the state transition tables of the Master command handler.
1478
Table 48 – State transition tables of the Master command handler STATE NAME
1479
1480
STATE DESCRIPTION
Inactive_0
Waiting on activation
Idle_1
Waiting on new command
MasterCommand_2
Waiting on transmission of command
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
1
Cast DL_Control.ind(PDVALID) to signal valid ProcessDataIn
T3
1
1
Cast DL_Control.ind(PDINVALID) to signal invalid ProcessDataIn
T4
1
2
-
T5
2
1
Transmission of MasterCommand
T6
1
0
-
INTERNAL ITEMS
TYPE
DL_Write_MasterCmd
Service
ACTION
DEFINITION DL_Write(0, MasterCommand), see Table B.2.
1481 1482
7.3.7.3
1483
Figure 50 shows the Device state machine of the control handler.
Device state machine of the command handler
DL_Control_VALID/ T2
/Initialization
Inactive_0
CH_Config_ACTIVE/ T1
Idle_1
1485
CommandHandler_2
[Done]/ T5
CH_Config_INACTIVE/ T6
1484
DL_Write_MasterCmd/ T4
DL_Control_INVALID/ T3
Figure 50 – Device state machine of the command handler
61131-9/WD V0.5 IEC 1486
– 89 –
Table 49 shows the state transition tables of the Device command handler.
1487
Table 49 – State transition tables of the Device command handler STATE NAME
1488
1489
Working Draft
STATE DESCRIPTION
Inactive_0
Waiting on activation
Idle_1
Waiting on next MasterCommand
CommandHandler_2
Decompose MasterCommand and cast specific actions (see B.1.2)
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
1
Cast PD-Valid(PDIN_VALID) to signal process data state to frame handler
T3
1
1
Cast PD-Valid(PDIN_INVALID) to signal process data state to frame handler
T4
1
2
-
T5
2
1
-
T6
1
0
-
INTERNAL ITEMS
TYPE
DL_Write_MasterCmd
Service
ACTION
DEFINITION CMD.ind(W, PARAMETER, 0, MasterCommand), see Table B.2
1490 1491
7.3.8
1492
7.3.8.1
1493 1494 1495 1496 1497
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.
1498
Table 50 – Event buffer
Event handler Events
Address
Parameter Name
Description
0x00
StatusCode
Summary of status and error information. Also used to control read access for individual messages.
0x01
EventQualifier 1
Type, mode and source of the first event
0x02
EventCode 1
16-bit event code of the first event
0x04
EventQualifier 2
Type, mode and source of the second event
0x05
EventCode 2
16-bit event code of the second event
0x03
0x06 … 0x10
EventQualifier 6
Type, mode and source of the sixth event
0x11
EventCode 6
16-bit event code of the sixth event
0x12 0x13 … 0x1F
1499
Reserved for future use
Working Draft
61131-9/WD V0.5 IEC
– 90 –
1500
7.3.8.2
1501 1502
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).
1503 1504 1505 1506
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.
1507 1508 1509 1510 1511
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).
1512 1513 1514
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.
1515 1516 1517
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.
1518
7.3.8.3
1519
Figure 51 shows the Master state machine of the event handler.
Event processing
Master state machine of the event handler
/Initialization
DL_Mode_COMLOSS/ T10
Inactive_0
DL_Mode_COMLOSS/ T7
EH_Config_ACTIVE/ T1
EventConfirmation_4
DL_EventConf/ T8
EventComTrig/ T3
EH_Config_INACTIVE/ T9
EventComTrig/ T2
Idle_1
EventComTrig/ T9
ReadEvent_2
[Events left]/ T5
[Details read]/ T4 [Events complete]/ T6
SignalEvent_3
1520 1521 1522
Figure 51 – Master state machine of the event handler Table 51 shows the state transition tables of the Master event handler.
1523
Table 51 – State transition tables of the Master event handler STATE NAME
STATE DESCRIPTION
Inactive_0
Waiting on activation
Idle_1
Waiting on next event indication or event confirmation
ReadEvent_2
Read event data set from Device
SignalEvent_3
Decompose event data and cast DL_Event to application layer (7.2.1.15)
61131-9/WD V0.5 IEC
– 91 –
STATE NAME
1524
1525
Working Draft
STATE DESCRIPTION
EventConfirmation_4
Waiting on event confirmation transmission
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
2
Read event status octet
T3
2
2
Read octets from event buffer
T4
2
3
-
T5
3
2
-
T6
3
1
-
T7
2
0
-
T8
1
4
-
T9
4
1
Cast CMD.req with event buffer confirmation by writing to "StatusCode" (Table 50)
T10
4
0
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
None
1526 1527
7.3.8.4
1528
Figure 52 shows the Device state machine of the event handler.
Device state machine of the event handler
EH_Config_ACTIVE/ T1
Inactive_0
DL_EventTrigger/ T3
Idle_1
EH_Config_INACTIVE/ T7
1530
EventConf/ T5
Figure 52 – Device state machine of the event handler Table 52 shows the state transition tables of the Device event handler.
1532
Table 52 – State transition tables of the Device event handler STATE NAME
1533
FreezeEventTable_2
[EventRead]/ T6
1529
1531
[EventRead]/ T4
ModifyEventPage/ T2
/Initialization
STATE DESCRIPTION
Inactive_0
Waiting on activation
Idle_1
Waiting on firing event flag
FreezeEventTable_2
Reading event buffer and waiting on event buffer confirmation
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
1
Change event table entries
T3
1
2
Indicate activated event flag state to frame handler
T4
2
2
Send event data by casting CMD.rsp with event data
ACTION
Working Draft TRANSITION
1534
61131-9/WD V0.5 IEC
– 92 –
SOURCE STATE
TARGET STATE
T5
2
1
Indicate cleared event flag state to frame handler. Mark all events as changeable
T6
1
1
Send event data by casting CMD.rsp with event data
T7
1
0
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
ModifyEventPage
Service
Any changes within the event buffer by DL_Event
EventRead
Service
CMD.ind(R, EVENT, Address, ...)
EventConf
Service
CMD.ind(W, EVENT, 0, DontCare)
1535 1536
8
1537
8.1
1538 1539
Figure 53 provides an overview of the structure and services of the Master application layer (AL).
Application layer General
Master applications Gateway application (configuration, parameterization, diagnosis, on-request, and process data)
AL_PDCycle
AL_SetOutput
AL_NewInput
AL_GetInput
DL_PDCycle
Process data objects DL_PDInputTransport
DL_Event
DL_EventConf
DL_Control
DL_ISDUAbort
DL_ISDUTransport
AL_Read
DL_WriteParam
On-request data AL objects Application Layer
Process Data Exchange
DL_PDOutputUpdate
AL_Event
AL_Control
AL_Abort
AL_Write
AL_Read
Diagnosis Unit
DL_Read
Coordination
1540
On-request Data Exchange
DL_ReadParam
Port x Handler
Data Storage
SM_PortMode
SM_SetPortConfig
SM_GetPortConfig
SM_Operate
Configuration Manager
DL_Write
System Management
DL_SetMode
On-request data handler
Process data handler
SIO DI / DO
Data Link Layer
1541
Figure 53 – Structure and services of the application layer (Master)
1542 1543
Figure 54 provides an overview of the structure and services of the Device application layer (AL).
61131-9/WD V0.5 IEC
– 93 –
Working Draft
Device applications Technology specific application (technology parameter, diagnosis, process data)
1544 1545
AL_PDCycle
AL_NewOutput
AL_SetInput
DL_PDCycle
DL_PDOutputTransport
Process data objects DL_PDInputUpdate
DL_EventTrigger
DL_Event
DL_Control
DL_ISDUAbort
DL_ISDUTransport
DL_WriteParam
DL_ReadParam
On-request data handler
Line handler
AL_GetOutput
Process Data Exchange (PDE)
AL_Event
AL_Abort
AL_Control
Event Dispatcher (ED)
On-request data AL objects Application Layer
SM_DeviceMode
SM_SetDeviceMode
SM_SetDeviceComm
SM_GetDeviceComm
SM_SetDeviceIdent
SM_GetDeviceIdent
System management
AL_Write
Data Storage (DS)
AL_Read
Parameter Manager (PM)
Process data handler
SIO DI / DO
Data Link Layer
Figure 54 – Structure and services of the application layer (Device)
1546 1547
8.2
1548
8.2.1
1549 1550 1551 1552
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.
1553
Table 53 – AL services within Master and Device
Application layer services AL services within Master and Device
Service name
Master
Device
AL_Read
R
I
AL_Write
R
I
AL_Abort
R
I
AL_GetInput
R
AL_NewInput
I
AL_SetInput AL_PDCycle
I
I
AL_GetOutput
R
AL_NewOutput
I
AL_SetOutput AL_Event AL_Control Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service
1554
R
R I/R R
R
Working Draft
61131-9/WD V0.5 IEC
– 94 –
1555
8.2.2
1556
8.2.2.1
1557 1558
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.
1559
Table 54 – AL_Read
AL Services AL_Read
Parameter name Argument
.req M
.ind
.rsp
M
Port
M
Index
M
M
Subindex
M
M
Result (+)
S
Port Data
Result (-)
ErrorInfo
S(=) M
M
M(=)
S
S(=)
Port
1560 1561 1562
.cnf
M M
M(=)
Argument The service-specific parameters of the service request are transmitted in the argument.
1563 1564
Port This parameter specifies the port number for the on-request data to be read.
1565
Parameter type: Unsigned8
1566 1567 1568 1569 1570 1571 1572 1573 1574 1575
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.
1576
Permitted values: 0 to 65 535 (See B.2.1 for constraints)
1577 1578 1579
Subindex This parameter specifies the element number within a structured on-request data object. A value of 0 indicates the entire set of elements.
1580
Permitted values: 0 to 255
1581 1582
Result (+): This selection parameter indicates that the service request has been executed successfully.
1583 1584
Port This parameter specifies the port number of the on-request data to be read.
1585 1586
Data This parameter specifies the read values of the on-request data.
61131-9/WD V0.5 IEC 1587 1588 1589
– 95 –
Working Draft
Parameter type: Octet string Result (-): This selection parameter indicates that the service request failed.
1590 1591
Port This parameter specifies the port number for the requested on-request data.
1592 1593
ErrorInfo This parameter contains error information to supplement the Result parameter.
1594
Parameter type: ErrorType (Annex C)
1595
Permitted values: NO_COMM, STATE_CONFLICT, TIMEOUT, or equivalents to Annex C
1596 1597
8.2.2.2
1598 1599
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.
1600
Table 55 – AL_Write
AL_Write
Parameter name Argument
.req M
.ind
M
Index
M
M
Subindex
M
M
Data
M
M(=)
S
Port
Result (-)
1601 1602 1603
S(=) M
S
Port ErrorInfo
.cnf
M
Port
Result (+)
.rsp
S(=) M
M
M(=)
Argument The service-specific parameters of the service request are transmitted in the argument.
1604 1605
Port This parameter specifies the port number for the on-request data to be written.
1606
Parameter type: Unsigned8
1607 1608 1609 1610 1611 1612 1613 1614
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.
1615
Permitted values: 1 to 65 535 (Table 91)
1616
Subindex
Working Draft
61131-9/WD V0.5 IEC
– 96 –
1617 1618
This parameter specifies the element number within a structured on-request data object. A value of 0 indicates the entire set of elements.
1619
Permitted values: 0 to 255
1620 1621
Data This parameter specifies the values of the on-request data to be written.
1622
Parameter type: Octet string
1623 1624 1625 1626 1627 1628
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.
1629 1630
Port This parameter specifies the port number for the requested on-request data.
1631 1632
ErrorInfo This parameter contains error information to supplement the Result parameter.
1633
Parameter type: ErrorType (Annex C)
1634
Permitted values: NO_COMM, STATE_CONFLICT, TIMEOUT or equivalents to Annex C
1635 1636
8.2.2.3
1637 1638 1639
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.
1640
Table 56 – AL_Abort
AL_Abort
Parameter name Argument Port
1641 1642 1643 1644 1645
.req M
.ind M
M
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.
1646 1647
8.2.2.4
1648 1649 1650
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.
1651
AL_GetInput
61131-9/WD V0.5 IEC
– 97 –
1652
Working Draft
Table 57 – AL_GetInput Parameter name Argument
.req
.cnf
M
Port
M
Result (+)
S
Port
M
InputData
M
Result (-)
1653 1654 1655 1656 1657 1658
S
Port
M
ErrorInfo
M
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.
1659 1660
Port This parameter specifies the port number for the process data to be read.
1661 1662 1663
InputData This parameter contains the values of the requested process input data of the specified port.
1664
Parameter type: Octet string
1665 1666
Result (-): This selection parameter indicates that the service request failed.
1667 1668
Port This parameter specifies the port number for the process data to be read.
1669 1670
ErrorInfo This parameter contains error information to supplement the Result parameter.
1671
Parameter type: ErrorType (Annex C)
1672
Permitted values: NO_COMM, NOT_CONNECTED, NO_DATA or equivalent to Annex C
1673 1674
8.2.2.5
1675 1676 1677
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.
1678
Table 58 – AL_NewInput
AL_NewInput
Parameter name Argument Port
1679 1680
.ind M M
Argument The service-specific parameters of the service request are transmitted in the argument.
Working Draft 1681 1682
61131-9/WD V0.5 IEC
– 98 –
Port This parameter specifies the port number of the received process data.
1683 1684
8.2.2.6
1685 1686
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.
1687
Table 59 – AL_SetInput
AL_SetInput
Parameter name Argument
.req
.cnf
M
InputData
M
Result (+)
S
Result (-)
S
ErrorInfo
M
1688 1689 1690 1691
Argument The service-specific parameters of the service request are transmitted in the argument.
1692 1693
InputData This parameter contains the process data values of the input data to be transmitted.
1694
Parameter type: Octet string
1695 1696
Result (+): This selection parameter indicates that the service request has been executed successfully.
1697 1698
Result (-): This selection parameter indicates that the service request has failed.
1699 1700
ErrorInfo This parameter contains error information to supplement the Result parameter.
1701
Parameter type: ErrorType (Annex C)
1702
Permitted values: STATE_CONFLICT or equivalent to Annex C
1703 1704
8.2.2.7
1705 1706 1707
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.
1708
Table 60 – AL_PDCycle
AL_PDCycle
Parameter name
.ind
Argument Port
1709 1710 1711
O
Argument The service-specific parameters of the service request are transmitted in the argument.
61131-9/WD V0.5 IEC 1712 1713
– 99 –
Working Draft
Port This parameter specifies the port number of the received new process data.
1714 1715
8.2.2.8
1716 1717
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.
1718
Table 61 – AL_GetOutput
AL_GetOutput
Parameter name Argument
.req
.cnf
M
Result (+)
S
OutputData
M
Result (-)
S
ErrorInfo
M
1719 1720 1721
Argument The service-specific parameters of the service request are transmitted in the argument.
1722 1723
Result (+): This selection parameter indicates that the service request has been executed successfully.
1724 1725 1726
OutputData This parameter contains the process data values of the requested output data for the specified port.
1727
Parameter type: Octet string
1728 1729
Result (-): This selection parameter indicates that the service request failed.
1730 1731
ErrorInfo This parameter contains error information to supplement the Result parameter.
1732
Parameter type: ErrorType (Annex C)
1733 1734
Permitted values: NO_COMM, NOT_CONNECTED, equivalents to Annex C
NO_DATA,
CONFIG_FAULT or
1735 1736
8.2.2.9
1737 1738
The AL_NewOutput local service indicates the receipt of updated output data within the process data of a Device. This service has no parameters.
AL_NewOutput
1739 1740
8.2.2.10
1741 1742
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.
AL_SetOutput
Working Draft
61131-9/WD V0.5 IEC
– 100 –
1743
Table 62 – AL_SetOutput Parameter name
.req
Argument
M
Port
M
OutputData
M
Result (+)
S
Port
M
Result (-)
S
Port
M
ErrorInfo
1744 1745 1746
.cnf
M
Argument The service-specific parameters of the service request are transmitted in the argument.
1747 1748
Port This parameter specifies the port number of the process data to be written.
1749 1750 1751
OutputData This parameter contains the ProcessDataIn the output data to be written at the specified port.
1752
Parameter type: Octet string
1753 1754 1755 1756 1757 1758
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.
1759 1760
Port This parameter specifies the port number for the process data to be written.
1761 1762
ErrorInfo This parameter contains error information to supplement the Result parameter.
1763
Parameter type: ErrorType (Annex C)
1764
Permitted values: STATE_CONFLICT or equivalents to Annex C
1765
8.2.2.11
1766 1767 1768 1769
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.
1770
Table 63 – AL_Event
AL_Event
Parameter name Argument
.req M
Port EventCount
M
.ind
.rsp
M
M
M
M
M
.cnf
61131-9/WD V0.5 IEC
– 101 –
Working Draft
Parameter name Event(1)
.req
.ind
Instance
M
M
Mode
M
M
Type
M
M
Local
.rsp
.cnf
M
EventCode
M
M
Instance
M
M
Mode
M
M
Type
M
M
… Event(n)
Local EventCode
1771 1772 1773
M M
M
Argument The service-specific parameters of the service request are transmitted in the argument.
1774 1775
Port This parameter specifies the port number of the event data.
1776 1777
EventCount This parameter specifies the number n (1…6) of Events in the Event buffer.
1778 1779 1780
Event(x) Depending on EventCount this parameter exists n times. Each instance contains the following elements.
1781 1782
Instance This parameter specifies the event source.
1783
Permitted values: unknown, PL, DL, AL, Application
1784 1785
Mode This parameter specifies the event mode.
1786
Permitted values: SINGLESHOT, APPEARS, DISAPPEARS
1787 1788
Type This parameter specifies the event category.
1789
Permitted values: ERROR, WARNING, MESSAGE
1790 1791 1792
Local This parameter indicates that the event was generated in the local communication section. Permitted values: LOCAL, REMOTE
1793 1794
EventCode This parameter contains a code identifying the event.
1795
Permitted values: see Annex C
1796
8.2.2.12
1797 1798
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.
AL_Control
Working Draft
61131-9/WD V0.5 IEC
– 102 –
1799
Table 64 – AL_Control Parameter name Argument
.req
.ind
M
M
Port
C
C
ControlCode
M
M
1800 1801 1802
Argument The service-specific parameters are transmitted in the argument.
1803 1804
Port This parameter specifies the port number of the event data.
1805 1806
ControlCode This parameter contains a code identifying the state of the process data.
1807
Permitted values: PD_VALID, PD_INVALID
1808 1809 1810
8.3
1811
8.3.1
1812 1813 1814 1815
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.
1816
8.3.2
1817
8.3.2.1
1818 1819 1820
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.
Application layer protocol Overview
On-request Data transfer OD state machine of the Master AL
61131-9/WD V0.5 IEC
– 103 –
Working Draft
/Initialization AL_Service_Portx/ T16
OnReq_Idle_0
AL_Abort_Portx/ T17
AL_Service_Portx/ T1
Build_DL_Service_1
[Argument_Error]/ T2
AL_Read[ Index =2 & ISDU_flag]/ T7
Await_DL_ISDU_cnf_3
Await_DL_Param_cnf_2
AL_Service/ T8
AL_Read[ Index >=2 & ISDU_flag]/ T6
DL_RWParam[ Octets_left]/ T10
AL_Abort/ T11
AL_Service/ T12
DL_ISDUTransport_cnf/ T15
DL_WriteParam_cnf[ Completed]/ T14 Build_AL_cnf_4
1821 1822 1823
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.
1824
Table 65 – States and transitions for the OD state machine of the Master AL STATE NAME
STATE DESCRIPTION
OnReq_Idle_0
AL service calls from the Master applications can be accepted within this state.
Build_DL_Service_1
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.
Await_DL_Param_cnf_2
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).
Await_DL_ISDU_cnf_3
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).
Build_AL_cnf_4
Within this state an AL service confirmation is created depending on an argument error, the DL service confirmation, or an AL_Abort.
1825 TRANSITION
SOURCE STATE
TARGET STATE
ACTION
T1
0
1
Memorize the port number "Portx".
T2
1
4
Prepare negative AL service confirmation.
T3
1
2
Prepare DL_ReadParam for Index 0 or 1.
T4
1
2
Prepare DL_WriteParam for Index 1.
Working Draft TRANSITION
1826
61131-9/WD V0.5 IEC
– 104 –
SOURCE STATE
TARGET STATE
T5
1
2
Prepare DL_WriteParam for Index 2 if the Device does not support ISDU.
T6
1
3
Prepare DL_ ISDUTransport(read)
T7
1
3
Prepare DL_ ISDUTransport(write)
T8
2
2
Return negative AL service confirmation on this asynchronous service call.
T9
2
4
All current DL service actions are abandoned and a negative AL service confirmation is prepared.
T10
2
2
Call next DL_ReadParam or DL_WriteParam service if not all OD are transferred.
T11
3
4
All current DL service actions are abandoned and a negative AL service confirmation is prepared.
T12
3
3
Return negative AL service confirmation on this asynchronous service call.
T13
2
4
Prepare positive AL service confirmation.
T14
2
4
Prepare positive AL service confirmation.
T15
3
4
Prepare positive AL service confirmation.
T16
4
0
Return AL service confirmation with port number "Portx".
T17
0
0
Return negative AL service confirmation.
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
Argument_Error
Bool
Illegal values within the service body, for example "Port number or Index out of range"
Completed
Bool
No more OD left for transfer
Octets_left
Bool
More OD for transfer
Portx
Variable
Service body variable indicating the port number
ISDU_Flag
Bool
Device supports ISDU
1827 1828
8.3.2.2
1829 1830
Figure 56 shows the state machine for the handling of On-request Data (OD) within the application layer of a Device.
OD state machine of the Device AL
/Initialization
AL_Abort/T11
DL_WriteParam_ind/T1
Await_AL_Write_rsp_1
DL_ISDUAbort/ T10
Idle_0
AL_Write_rsp/T2 AL_Write_rsp/ T8
AL_Read_rsp/ T7
DL_ReadParam_ind/ T3 AL_Read_rsp/ T4
DL_ISDUTransport _ind[DirRead]/ T5
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 –
Table 66 – States and transitions for the OD state machine of the Device AL STATE NAME
STATE DESCRIPTION
Idle_0
The Device AL is waiting on subordinated DL service calls triggered by Master messages.
Await_AL_Write_rsp_1
The Device AL is waiting on a response from the technology specific application (write access to Direct Parameter page).
Await_AL_Read_rsp_2
The Device AL is waiting on a response from the technology specific application (read access to Direct Parameter page).
Await_AL_RW_rsp_3
The Device AL is waiting on a response from the technology specific application (read or write access via ISDU).
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
Create AL_Write.
T2
1
0
Create DL_WriteParam (16…31).
T3
0
2
Create AL_Read.
T4
2
0
Create DL_ReadParam (0…31).
T5
0
3
Create AL_Read.
T6
0
3
Create AL_Write.
T7
3
0
Create DL_ ISDUTransport(read)
T8
3
0
Create DL_ ISDUTransport(write)
T9
3
0
Current AL_Read or AL_Write abandoned upon this asynchronous AL_Abort service call. Return negative DL_ ISDUTransport (see 3.3.6).
T10
3
0
Current waiting on AL_Read or AL_Write abandoned.
T11
0
0
Current DL_ ISDUTransport abandoned. All OD are set to "0".
1835
1836
Working Draft
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
DirRead
Bool
Access direction: DL_ ISDUTransport(read) causes an AL_Read
DirWrite
Bool
Access direction: DL_ ISDUTransport(write) causes an AL_Read
1837 1838
8.3.2.3
1839 1840
Figure 57 through Figure 59 demonstrate complete interactions between Master and Device for several On-request Data exchange use cases.
1841 1842 1843 1844
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)
Sequence diagrams for On-request Data
Working Draft Master App
61131-9/WD V0.5 IEC
– 106 – Master AL
Master DL Portx
Device DL
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) DL_ISDUTransport_req() Message() DL_ISDUTransport_ind()
AL_Read_ind()
AL_Read_rsp() DL_ISDUTransport_rsp() Message()
Device application responds with error information "Index not available" (0x8011, IDX_NOTAVAIL)
DL_ISDUTransport_cnf()
AL_Read_cnf()
ErrorInfo: IDX_NOTAVAIL
ErrorInfo: IDX_NOTAVAIL
1854 1855
Figure 58 – Sequence diagram for On-request Data in case of errors
1856 1857
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).
1858
NOTE
See Table 91 for system constants such as ISDU timeout.
Master App
Master AL
Master DL Portx
Device DL
Device AL
Device App
AL_Read_req() DL_ISDUTransport_req() Message()
DL_ISDUTransport_ind() AL_Read_ind() Tm(5500)
DL_ISDUTransport_cnf() AL_Read_cnf() ErrorInfo = TIMEOUT
ErrorInfo = TIMEOUT
Reaction of the Device application missing or too late (usually an implementation error) AL_Read_rsp()
Message()
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
61131-9/WD V0.5 IEC
– 108 –
1861
8.3.3
1862
8.3.3.1
1863
Figure 60 shows the Event state machine of the Master application layer.
Event processing Event state machine of the Master AL
/Initialization Event_inactive_0
Activate/ T1
Deactivate/ T2 Event_idle_1
DL_Event_ind[Diag_Portx]/ T3
AL_Event_rsp/ T6
DL_Event_ind[Events_done]/ T5
Read_Event_Set_2
DU_Event_handling_3
DL_Event_ind[Events_left]/ T4
1864 1865
Figure 60 – Event state machine of the Master AL
1866 1867
Table 67 specifies the states and transitions of the Event state machine of the Master application layer.
1868
Table 67 – State and transitions of the Event state machine of the Master AL STATE NAME Event_inactive_0
The AL Event handling of the Master is inactive.
Event_idle_1
The Master AL is ready to accept DL_Events (diagnosis information) from the DL.
Read_Event_Set_2
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).
DU_Event_handling_3
The Master AL remains in this state as long as the Diagnosis Unit (see 11.5) did not acknowledge the AL_Event.ind.
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
0
-
T3
1
2
-
T4
2
2
-
T5
2
3
AL_Event.ind
T6
3
1
DL_EventConf.req
1869
1870
STATE DESCRIPTION
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
Diag_Portx
Bool
Event set contains diagnosis information with details.
Events_done
Bool
Event set is processed.
Events_left
Bool
Event set not yet completed.
61131-9/WD V0.5 IEC
– 109 –
Working Draft
1871
8.3.3.2
1872
Figure 61 shows the Event state machine of the Device application layer
Event state machine of the Device AL
/Initialization
Event_inactive_0
Activate/ T1
Deactivate/ T2 Event_idle_1
AL_Event_req/ T3
DL_EventTrigger_cnf/ T4
Await_Event_response_2
1873 1874
Figure 61 – Event state machine of the Device AL
1875 1876
Table 68 specifies the states and transitions of the Event state machine of the Device application layer
1877
Table 68 – State and transitions of the Event state machine of the Device AL STATE NAME
STATE DESCRIPTION
Event_inactive_0
The AL Event handling of the Device is inactive.
Event_idle_1
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.
Await_event_response_2
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.
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
0
-
T3
1
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)
T4
2
1
A DL_EventTrigger confirmation triggers an AL_Event confirmation.
1878
1879
INTERNAL ITEMS
TYPE
ACTION
DEFINITION
none
1880 1881 1882
8.3.4
1883 1884
Figure 62 and Figure 63 demonstrate complete interactions between Master and Device for output and input Process Data use cases.
Process data cycles
Working Draft 1885 1886 1887
61131-9/WD V0.5 IEC
– 110 –
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 )
...
AL_NewOutput_ind()
DL_PDOutputUpdate_req()
AL_Set Output_req(Portx )
Message()
... DL_PDOutputUpdate_req() Message()
...
DL_PDOutputTransport_ind()
...
AL_NewOutput_ind()
...
DL_PDOutputTransport_ind()
AL_NewOutput_ind()
Asynchronous ac cess to output Proc ess Data
AL_Get Output_req()
AL_Get Output_cnf ()
1888 1889
Figure 62 – Sequence diagram for output Process Data
1890 1891 1892
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
– 111 –
Master AL
Master DL Portx
Working Draft Device DL
Device AL
Device App
Message() DL_PDCycle_ind() AL_PDCycle_ind() DL_PDInputTransport_req() AL_NewInput_ind()
AL_SetInput_req() DL_PDInputUpdate_req()
Device application sets input Process Data for cyclic transmission by the frame handler
DL_PDInputUpdate_cnf() AL_SetInput_cnf() Message() DL_PDCycle_ind()
DL_PDInputTransport_req() AL_NewInput_ind()
...
...
AL_PDCycle_ind()
...
Message()
...
...
DL_PDCycle_ind()
AL_PDCycle_ind()
DL_PDInputTransport_req() AL_NewInput_ind()
AL_GetInput_req()
Asynchronous access to input Process Data
AL_GetInput_cnf()
1893 1894
Figure 63 – Sequence diagram for input Process Data
1895
9
1896
9.1
1897 1898 1899 1900 1901
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.
1902
9.2
1903
9.2.1
1904 1905
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".
1906
The Master SM adjusts ports through
1907
establishing the required communication protocol revision
1908
checking the Device compatibility (actual Device identifications match expected values)
1909
adjusting adequate Master F-sequence types and MasterCycleTimes
System management (SM) General
System management of the Master Overview
Working Draft
61131-9/WD V0.5 IEC
– 112 –
1910
For this it uses the following services shown in Figure 64:
1911 1912 1913
SM-SetPortConfig transfers the necessary Device parameters (configuration data) from Configuration Management (CM) to System Mangement (SM). The port is then started implicitely.
1914 1915 1916
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.
1917
SM-GetPortConfig provides the actual and effective parameters.
1918
SM-Operate switches the ports into the "Operate" mode.
1919 1920
Figure 64 provides an overview of the structure and services of the Master system management.
1921 1922
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) Data Storage
On-request Data Exchange
SM_PortMode
Diagnosis Unit
Process Data Exchange
DL_Mode
System Management
PL_Mode.req
PL_WakeUp.req
DL_PDCycle
DL_PDInputTransport
DL_PDOutputUpdate
DL_EventConf
DL_Event
PD.cnf
PD.req
DL-B PDTrig
DL_Control
CMD.cnf
PDInvalid
FHInfo CMD.req
ComTrig
Master DL-mode handler
Process data handler
CMD.req
DL_SetMode
EventFlag.ind
DL_Write
CMD.cnf
On-request data handler
DL_Read Coordination
DL_ISDUAbort
DL_ISDUTransport
AL_Read
Port x Handler
DL_Write Param
Application Layer DL_ReadParam
SM_SetPortConfig
SM_GetPortConfig
SM_Operate
Configuration Manager
DL-A
Frame handler PL_Transfer.req
SIO DI / DO PL_Transfer.ind
Mode switch Inactive
(Wake-up)
(Coded switching)
(Switching signal)
Physical Layer (port)
1923 1924
Figure 64 – Structure and services of the Master system management
1925 1926 1927
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.
1928
This particular use case is characterized by the following statements:
1929
The Device for the available configuration is connected and validation is OK
1930
The Device uses the correct protocol version according to this specification
1931 1932
The configured InspectionLevel is "type compatible" (SerialNumber is read out of the Device and not checked).
61131-9/WD V0.5 IEC 1933
– 113 –
Working Draft
Dotted arrows in Figure 65 represent response services to an initial service.
1934 Master App
CM
OperatingMode(SDCI) (Port x)
SM
AL_Port_x
DL_Port_x
SM_SetPortConfig_req()
Actions: - Wake up - Transmission rate detected - --> State STARTUP
(Parameter list) DL_SetMode_req() (Startup) DL_Mode_ind(STARTUP)
Actions: - Check protocol revision - Check device compatibility - Frametype (PREOPERATE) - Cycle time (PREOPERATE)
Actions: - Read Direct Parameter 1
DL_Read() Reply() (Direct Parameter 1)
...
DL_SetMode_req(PREOPERATE) (Value list)
Actions: --> State PREOPERATE
DL_Mode_ind(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
Figure 65 – Sequence chart of the use case "port x setup"
1937 1938
9.2.2
1939
9.2.2.1
1940 1941 1942
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.
SM Master services Overview
Working Draft 1943
61131-9/WD V0.5 IEC
– 114 – Table 69 – SM services within the Master Service name
Master
SM_SetPortConfig
R
SM_GetPortConfig
R
SM_PortMode
I
SM_Operate
R
Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service
1944 1945
9.2.2.2
1946 1947
The SM_SetPortConfig service is used to set up the requested Device configuration. The parameters of the service primitives are listed in Table 70.
1948
Table 70 – SM_SetPortConfig
SM_SetPortConfig
Parameter name Argument ParameterList
.req M M
Result (+) Port Number
Result (-)
1949 1950 1951
.cnf
S M
S
Port Number
M
ErrorInfo
M
Argument The service-specific parameters of the service request are transmitted in the argument.
1952 1953
ParameterList This parameter specifies the configured Device parameter on a Master port.
1954
Parameter type: Record
1955
Record Elements:
1956 1957
Port Number This parameter specifies the port number
1958 1959
ConfiguredCycleTime This parameter specifies the requested cycle time for OPERATE mode
1960
Permitted values: 0 = FreeRunning, time in µs
1961 1962
TargetMode This parameter specifies the requested operational mode
1963
Permitted values: INACTIVE, DI, DO, CFGCOM, AUTOCOM (see Table 72)
1964 1965
ConfiguredBaudrate: This parameter specifies the requested transmission rate
1966
Permitted values : AUTO, COM1, COM2, COM3
1967 1968
ConfiguredRevisionID (CRID): Data length: 1 octet for the protocol version (see B.1.6)
61131-9/WD V0.5 IEC
– 115 –
Working Draft
1969 1970
InspectionLevel: Permitted values: NO_CHECK, TYPE_COMP, IDENTICAL (see Table 71)
1971 1972
ConfiguredVendorID (CVID) Data length: 2 octets from the official vendor list (see Annex K)
1973 1974
ConfiguredDeviceID (CDID) Data length: 3 octets
1975 1976
ConfiguredFunctionID (CFID) Data length: 2 octets
1977 1978
ConfiguredSerialNumber (CSN) Data length: up to 16 octets
1979 1980 1981 1982 1983 1984 1985
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
1986 1987
Port Number This parameter specifies the port number
1988 1989
ErrorInfo This parameter contains error information to supplement the Result parameter
1990
Permitted values: OUT_OF_RANGE, STATE_CONFLICT
1991 1992
Table 71 specifies the coding of the different InspectionLevels (IL).
1993
Table 71 – Definition of the InspectionLevel (IL) Parameter
InspectionLevel (IL) NO_CHECK
TYPE_COMP
IDENTICAL
DeviceID (compatible)
-
yes
yes
VendorID
-
yes
yes
SerialNumber
-
-
yes
1994 1995
Table 72 specifies the coding of the different Target Modes.
1996
Table 72 – Definitions of the Target Modes Target Mode
1997
Definition
CFGCOM
Device communicating in mode CFGCOM after successful validation
AUTOCOM
Device communicating in mode AUTOCOM without validation
INACTIVE
Communication disabled, no DI, no DO
DI
Port in digital input mode (SIO)
DO
Port in digital output mode (SIO)
Working Draft
61131-9/WD V0.5 IEC
– 116 –
1998 1999
CFGCOM is a Target Mode based on a configuration with the help of an IODD and consistency checking of RID, VID, DID.
2000 2001
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.
2002
9.2.2.3
2003 2004
The SM_GetPortConfig service is used to acquire the real (actual) Device configuration. The parameters of the service primitives are listed in Table 73.
2005
Table 73 – SM_GetPortConfig
SM_GetPortConfig
Parameter name Argument Port Number
.req M M
Result (+) Parameterlist
Result (-)
2006 2007 2008 2009 2010 2011 2012
.cnf
S(=) M
S(=)
Port Number
M
ErrorInfo
M
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.
2013 2014
ParameterList This parameter specifies the configured Device parameter on a Master port.
2015
Parameter type: Record
2016
Record Elements:
2017 2018
PortNumber This parameter specifies the port number.
2019 2020
TargetMode This parameter indicates the operational mode
2021
Permitted values: INACTIVE, DI, DO, CFGCOM, AUTOCOM
2022 2023
RealBaudrate This parameter indicates the actual transmission rate
2024
Permitted values: COM1, COM2, COM3
2025 2026
RealCycleTime This parameter indicates the real (actual) cycle time
2027 2028
RealRevision (RRID) Data length: 1 octet for the protocol version (see B.1.6)
2029 2030
RealVendorID (RVID) Data length: 2 octets from the official vendor list (Annex K)
2031
RealDeviceID (RDID)
61131-9/WD V0.5 IEC
– 117 –
2032
Data length: 3 octets
2033 2034
RealFunctionID (RFID) Data length: 2 octets
2035 2036
RealSerialNumber (RSN) Data length: up to 16 octets
2037 2038
Working Draft
Result (-): This selection parameter indicates that the service request failed
2039 2040
Port Number This parameter specifies the port number
2041 2042
ErrorInfo This parameter contains error information to supplement the Result parameter
2043
Permitted values: OUT_OF_RANGE
2044
All parameters shall be set to "0" if there is no information available.
2045
9.2.2.4
2046 2047
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.
2048
Table 74 – SM_PortMode
SM_PortMode
Parameter name
.ind
Argument
2049 2050 2051
M
Port Number
M
Mode
M
Argument The service-specific parameters of the service request are transmitted in the argument.
2052 2053
Port Number This parameter specifies the port number
2054 2055 2056 2057
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
2058
Table 75 defines the port error modes. These shall be reported to the Master application.
2059
Table 75 – Definition of the port error modes Mode
2060
Definition
COMLOSS
Communication failed, new wake-up procedure required
REV_FAULT
Incompatible protocol revision
COMP_FAULT
Incompatible Device according to the InspectionLevel
SERNUM_FAULT
Mismatching SerialNumber according to the InspectionLevel
Working Draft
61131-9/WD V0.5 IEC
– 118 –
2061
9.2.2.5
2062 2063 2064
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.
2065
Table 76 – SM_Operate
SM_Operate
Parameter name
.req
Result (+)
Result (-) ErrorInfo
.cnf S
S M
2066 2067 2068
Result (+): This selection parameter indicates that the service request has been executed successfully.
2069 2070
Result (-): This selection parameter indicates that the service request failed.
2071 2072
ErrorInfo This parameter contains error information to supplement the Result parameter.
2073
Permitted values: TIMING_CONFLICT
2074 2075
9.2.3
2076
9.2.3.1
2077 2078 2079 2080
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.
2081 2082 2083
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.
2084 2085
The corresponding decision logic is demonstrated via activity diagrams (Figure 68, Figure 69, Figure 70, and Figure 73).
2086
9.2.3.2
2087 2088 2089 2090 2091
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".
SM Master protocol Overview
SM Master state machine
61131-9/WD V0.5 IEC
– 119 –
Working Draft
/Inialization
PortInactive_0 DL_Mode_COMLOSS/ T3
SM_SetPortConfig[INACTIVE]/ T14
DL_Mode_STARTUP/ T1
SM_SetPortConfig[CFGCOM or AUTOCOM]/ T15
JoinPseudoState_9 enex_6
checkCompatibility_1 enex_1 enex_5
enex_3
enex_2 [CompOK]/ T2
[CompFault]/ T7
enex_4 [RevisionFault]/ T6
waitonDLPreoperate_2
[V10CompOK]/ T4
waitonDLOperate_7
DL_Mode_PREOPERATE/ T8
[V10CompFault]/ T5 ValidationFault_6
DL_Mode_OPERATE/ T9
checkSerNum_3
enex_12
enex_11
enex_10
[SerNumOK]/ T10
[SerNumFault]/ T11
SM_SetPortConfig[DI or DO]/ T16 DIDO_8
wait_4
SM_Operate/ T12 SMOperate_5
DL_Mode_OPERATE/ T13
2092 2093 2094
Figure 66 – Main Master state machine of the System Management Table 77 shows the state transition tables of the Master system management.
2095
Table 77 – State transition tables of the Master system management STATE NAME
STATE DESCRIPTION
PortInactive_0
No communication
CheckCompatibility_1
Port is started and revision and Device compatibility is checked. See Figure 67.
waitonDLPreoperate_2
Wait until the state PREOPERATE is established and all the On-Request handlers are started. Port is ready to communicate.
CheckSerNum_3
SerialNumber is checked depending on the InspectionLevel (IL). See Figure 72.
wait_4
Port is ready to communicate and waits on service SM_Operate from CM.
SM Operate_5
Port is in state OPERATE and performs cyclic process data exchange.
ValidationFault_6
Port is ready to communicate. However, cyclic process data exchange cannot be performed due to incompatibilities.
waitonDLOperate_7
Wait on the requested state OPERATE in case of protocol version V1.0. The
Working Draft
61131-9/WD V0.5 IEC
– 120 –
STATE NAME
STATE DESCRIPTION SerialNumber can be read thereafter.
DIDO_8
Port will be switched into the DI or DO mode (SIO, no communication)
JoinPseudoState_9
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)
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
CompRetry = 0
T2
1
2
DL_SetMode.req (PREOPERATE, ValueList)
T3
1,2,3,4,5, 6,7
0
DL_SetMode.req (INACTIVE ) and SM_Mode.ind (COMLOSS) due to communiacation fault
T4
1
7
DL_SetMode.req (OPERATE, ValueList)
T5
1
6
SM_Mode.ind (COMP_FAULT), DL_SetMode.req (OPERATE, ValueList)
T6
1
6
SM_Mode.ind (REV_FAULT), DL_SetMode.req (PREOPERATE, ValueList)
T7
1
6
SM_Mode.ind (COMP_FAULT), DL_SetMode.req (PREOPERATE, ValueList)
T8
2
3
-
T9
7
3
-
T10
3
4
SM_Mode.ind (CFGCOM or AUTOCOM)
T11
3
6
SM_Mode.ind (SERNUM_FAULT)
T12
4
5
DL_SetMode.req (OPERATE, ValueList)
T13
5
5
-
T14
0,4,5,6,8
0
SM_Mode.ind (INACTIVE), DL_SetMode.req (INACTIVE)
T15
0,4,5,6,8
0
DL_SetMode.req (STARTUP, ValueList), PL_Mode.req (SDCI)
T16
0,4,5,6,8
8
PL_Mode.req (SIO), SM_Mode.ind (DI or DO), DL_SetMode.req (INACTIVE)
2096
2097 INTERNAL ITEMS
ACTION
TYPE
DEFINITION
CompOK
Bool
See Figure 70
CompFault
Bool
See Figure 70; error variable COMP_FAULT
RevisionFault
Bool
See Figure 68; error variable REV_FAULT
SerNumFault
Bool
See Figure 73; error variable SERNUM_FAULT
SerNumOK
Bool
See Figure 73
V10CompFault
Bool
See Figure 69; error variable COMP_FAULT
V10CompOK
Bool
See Figure 69
INACTIVE
Variable
A target mode in service SM_SetPortConfig
CFGCOM, AUTOCOM
Variables
Target Modes in service SM_SetPortConfig
2098 2099
9.2.3.3
2100
Figure 67 shows the SM Master submachine checkCompatibility_1.
SM Master submachine "Check Compatibility"
61131-9/WD V0.5 IEC
– 121 –
Working Draft
checkCompatibility_1
[WriteDone]/ T24
ReadComParameter_20
[V10]/ T21
[V10]/ T20
JoinPseudoState_25
enex_1
CheckVxy_22
DL_Mode_COMLOSS/ T3
do check revision
RestartDevice_24 do write parameter
CheckCompV10_21 do check comp V10
do check comp
[CompOK]/ T2
[CompFault]/ T7
enex_2
2102
[RevisionFault]/ T6
[RevisionOK]/ T22
CheckComp_23
[RetryStartup]/ T23
2101
[RetryStartup]/ T25
enex_3
[V10CompOK]/ T4
enex_5
enex_4
[V10CompFault]/ T5
enex_6
Figure 67 – SM Master submachine CheckCompatibility_1
2103
Table 78 shows the state transition tables of the Master submachine checkCompatibility_1.
2104
Table 78 – State transition tables of the Master submachine CheckCompatibility_1 STATE NAME
2105
2106
STATE DESCRIPTION
ReadComParameter_20
Acquires communication parameters from Direct Parameter Page 1 (0x02 to 0x06) via service DL_Read (Table B.1).
CheckCompV10_21
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.
CheckVxy_22
A check is performed whether the configured revision (CRID) matches the real (actual) revision (RRID) according to Figure 68.
CheckComp_23
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.
RestartDevice_24
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.
JoinPseudoState_25
This pseudo state is used instead of a UML join bar. No guards involved.
TRANSITION
SOURCE STATE
TARGET STATE
T20
20
21
-
T21
20
22
DL_Write (0x00,0x95 MasterCommand “MasterIdent”), see Table B.2
T22
22
23
-
T23
23
24
-
T24
24
20
-
T25
22
24
CompRetry = CompRetry +1
ACTION
Working Draft
61131-9/WD V0.5 IEC
– 122 –
INTERNAL ITEMS
TYPE
DEFINITION
CompOK
Bool
See Figure 70
CompFault
Bool
See Figure 70; error variable COMP_FAULT
RevisionFault
Bool
See Figure 68; error variable REV_FAULT
RevisionOK
Bool
See Figure 68
SerNumFault
Bool
See Figure 73; error variable SERNUM_FAULT
SerNumOK
Bool
See Figure 73
V10
Bool
Real revision = V1.0 (B.1.6)
V10
Bool
Real revision V1.0 (B.1.6)
V10CompFault
Bool
See Figure 69; error variable COMP_FAULT
V10CompOK
Bool
See Figure 69
RetryStartup
Bool
See Figure 68 and Figure 70
CompRetry
Variable
Internal counter
WriteDone
Bool
Finalization of the restart service sequence
2107 2108
Some states contain complex logic to deal with the compatibility and validity checks. The following figures are demonstrating the context.
2109 2110 2111 2112 2113
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.
2114 2115
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]
[CompRetry = 1]
2116 2117
RetryStartup (T23)
RevisionFault (T6)
Figure 68 – Activity (check revision) for state "CheckVxy"
2118 2119
Figure 69 shows the decision logic for the V10 compatibility check in state "CheckCompV10".
61131-9/WD V0.5 IEC
– 123 –
[IL: NO_CHECK]
D3
Working Draft
V10CompOK (T4)
[IL: TYPE_COMP or IDENTICAL]
D4
[CVID = RVID and CDID = RDID]
[CVID RVID or CDID RDID]
V10CompFault (T5)
Key IL = Inspection level
2120 2121
V10CompOK (T4)
Figure 69 – Activity (check comp V10) for state "CheckCompV10"
2122 2123
Figure 70 shows the decision logic for the compatibility check in state "CompCheck".
D5
[IL: NO_CHECK]
CompOK (T2)
Device starts
CompFault (T7)
Incompatible --> Error
RetryStartup (T23)
Device restart with RVID, RDID
[IL: TYPE_COMP or IDENTICAL]
D6
[CVID RVID]
[CVID = RVID]
[CompRetry = 0 and CDID RDID] D7
[CompRetry = 1 and CDID RDID]
CompFault (T7)
Incompatible --> Error
Key IL = Inspection level
2124 2125
Figure 70 – Activity (check comp) for state "CheckComp"
2126 2127
Figure 71 shows the activity (write parameter) in state "RestartDevice".
Working Draft
61131-9/WD V0.5 IEC
– 124 –
WriteDone =FALSE
[AUTOCOM]
DL_Write (0x04, CRID) DL_Write (0x00,0x96, "DeviceIdent") DL_Read (0x02) (dummy cycle)
D8
[CFGCOM]
DL_Write (0x04, CRID) DL_Write (0x09…0x0B, CDID) DL_Write (0x00,0x96, "DeviceIdent") DL_Read (0x02) (dummy cycle)
[CommError]
[CommError] [OK]
[OK]
DL_Mode_COMLOSS (T3)
DL_Mode_COMLOSS (T3)
WriteDone = TRUE
(T24)
2128 2129
Figure 71 – Activity (write parameter) in state "RestartDevice"
2130 2131
9.2.3.4
2132
Figure 72 shows the SM Master submachine "checkSerNum_3". This check is mandatory.
SM Master submachine "Check serial number"
checkSerNum_3
ReadSerNum_30 enex_12
DL_Mode_COMLOSS/ T3
[SRead-]/ T30
[SReadOK]/ T31
CheckSerNum_31 do check serial number
[SerNumOK]/ T10
enex_11
2133 2134 2135 2136
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
2137
[SerNumFault]/ T11
STATE DESCRIPTION
ReadSerNum_30
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.
CheckSerNum_31
The configured (CSN) and the real (RSN) SerialNumber are checked depending on the InspectionLevel (IL) according to Figure 73.
61131-9/WD V0.5 IEC TRANSITION
2138
– 125 –
SOURCE STATE
TARGET STATE
T30
40
41
T31
40
41
INTERNAL ITEMS
Working Draft ACTION
TYPE
DEFINITION
SRead-
Bool
Negative response of service AL_Read (Index 0x0015)
SReadOK
Bool
SerialNumber read correctly
SERNumOK
Bool
See Figure 73
SERNumFault
Bool
See Figure 73
2139 2140
Figure 73 shows the decision logic (activity) for the state CheckSerNum_3.
[IL: not IDENTICAL]
D9
SerNumOK (T10)
[IL: IDENTICAL]
D10
[SRead-]
SerNumFault (T11)
[SReadOK]
[CSN RSN] D11
[CSN = RSN]
2141 2142
SerNumFault (T11)
SerNumOK (T10)
Figure 73 – Activity (check SerialNumber) for state CheckSerNum_3
2143 2144
9.2.3.5
2145 2146 2147
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.
2148 2149 2150 2151 2152 2153 2154 2155
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.
2156
Rules for the usage of F-sequence types
Working Draft
61131-9/WD V0.5 IEC
– 126 –
2157
9.3
2158
9.3.1
2159 2160
Figure 74 provides an overview of the structure and services of the Device system management.
System management of the Device Overview
Device applications Technology specific application (technology parameter, diagnosis, process data) Data Storage (DS)
Event Dispatcher (ED)
Process Data Exchange (PDE)
DL_Mode
PL_Mode.req
CMD.rsp
PL_WakeUp.ind
DL_PDCycle
DL_PDOutputTransport
DL_PDInputUpdate
PD.rsp
DL_Event
DL_EventTrigger
PD.ind
FHInfo CMD.ind
DL-B
PDValid
Device DL-mode handler
Process data handler
CMD.rsp
DL_Write
CMD.ind
DL_Read
EventFlag
On-request data handler
Line Handler
System Management
DL_Control
DL_ISDUAbort
DL_ISDUTransport
DL_ReadParam
DL_WriteParam
Application Layer SM_DeviceMode
SM_SetDeviceMode
SM_SetDeviceComm
SM_GetDeviceComm
SM_SetDevciceIdent
SM_GetDeviceIdent
Parameter Manager (PM)
DL-A
Frame handler PL_Transfer.ind
SIO DI / DO PL_Transfer.req
Mode switch Coded switching
Wake-up
2161
Switching signal
Physical Layer
2162
Figure 74 – Structure and services of the system management (Device)
2163 2164 2165
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.
2166 2167 2168 2169
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).
2170 2171 2172
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).
2173 2174
The SM provides the Device identification parameters through the Device applications interface.
2175 2176 2177 2178
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
– 127 – DL
Working Draft
SM
Device App
SM_SetDeviceMode(IDLE) PL_SetMode(INACTIVE) SM_DeviceMode(IDLE) SM_SetDeviceCom(Initial parameter)
Device default communication and identification parameter
SM_SetDeviceIdent(Initial parameter) SM_SetDeviceMode(SIO)
PL_SetMode(DI | DO | INACTIVE)
SM_DeviceMode(SIO)
WakeUp request from master
SIO mode active PL_WakeUp(ind) DL_Mode(STARTUP) PL_SetMode(COMx) SM_DeviceMode(COMSTARTUP) Errors /events - Tdsio expired - Fallback
DL_Mode(INACTIVE)
Communication startup and data exchange
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
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.
2182 2183
9.3.2
2184
9.3.2.1
2185 2186
This section describes the services the Device system management provides to its applications as shown in Figure 74.
2187 2188
Table 80 lists the assignment of the Device to its role as initiator or receiver for the individual system management service.
SM Device services Overview
Working Draft 2189
61131-9/WD V0.5 IEC
– 128 – Table 80 – SM services within the Device Service name
Device
SM_SetDeviceCom
R
SM_GetDeviceCom
R
SM_SetDeviceIdent
R
SM_GetDeviceIdent
R
SM_SetDeviceMode
R
SM_DeviceMode
I
Key (see 3.3.4) I Initiator of service R Receiver (Responder) of service
2190 2191
9.3.2.2
2192 2193 2194
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.
2195
Table 81 – SM_SetDeviceCom
SM_SetDeviceCom
Parameter name Argument ParameterList
.req
.cnf
M M
Result (+)
S
Result (-)
S
ErrorInfo
M
2196 2197 2198
Argument The service-specific parameters of the service request are transmitted in the argument.
2199 2200
ParameterList This parameter specifies the configured communication parameters for a Device.
2201
Parameter type: Record
2202
Record Elements:
2203 2204
SupportedSIOMode This parameter specifies the SIO mode supported by the Device.
2205
Permitted values: INACTIVE, DI, DO
2206 2207
SupportedBaudrate This parameter specifies the transmission rates supported by the Device.
2208
Permitted values: COM1, COM2, COM3
2209 2210
MinCycleTime This parameter specifies the minimum cycle time supported by the Device (B.1.4).
2211 2212 2213 2214
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
– 129 –
Working Draft
2215 2216
- OPERATE F-sequence types - PREOPERATE F-sequence types
2217 2218
RevisionID (RID) This parameter specifies the protocol revision RID (B.1.6) supported by the Device.
2219 2220
ProcessDataIn This parameter specifies the length of process data to be sent to the Master (B.1.7).
2221 2222
ProcessDataOut This parameter specifies the length of process data to be sent by the Master (B.1.8).
2223 2224 2225
Result (+): This selection parameter indicates that the service request has been executed successfully.
2226 2227 2228
Result (-): This selection parameter indicates that the service request failed.
2229 2230
ErrorInfo This parameter contains error information to supplement the Result parameter.
2231
Permitted values: STATE_CONFLICT
2232 2233
9.3.2.3
2234 2235
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.
2236
Table 82 – SM_GetDeviceCom
SM_GetDeviceCom
Parameter name Argument ParameterList
.cnf
M M
Result (+)
S
Result (-)
S
ErrorInfo
2237 2238 2239
.req
M
Argument The service-specific parameters of the service request are transmitted in the argument.
2240 2241
ParameterList This parameter specifies the configured communication parameter for a Device.
2242
Parameter type: Record
2243
Record Elements:
2244 2245
CurrentMode This parameter specifies the current SIO or Communication Mode by the Device.
2246
Permitted values: INACTIVE, DI, DO, COM1, COM2, COM3
2247 2248 2249
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.
2250
F-sequence Capability
Working Draft
61131-9/WD V0.5 IEC
– 130 –
2251 2252 2253 2254 2255
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
2256 2257 2258
RevisionID (RID) This parameter contains the current protocol revision RID (B.1.6) within the system management of the Device.
2259 2260 2261
ProcessDataIn This parameter provides the current length of process data to be sent to the Master (B.1.7).
2262 2263 2264
ProcessDataOut This parameter provides the current length of process data to be sent by the Master (B.1.8).
2265 2266 2267
Result (+): This selection parameter indicates that the service request has been executed successfully.
2268 2269
Result (-): This selection parameter indicates that the service request failed.
2270 2271
ErrorInfo This parameter contains error information to supplement the Result parameter.
2272
Permitted values: STATE_CONFLICT
2273
9.3.2.4
2274 2275
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.
2276
Table 83 – SM_SetDeviceIdent
SM_SetDeviceIdent
Parameter name Argument ParameterList
.cnf
M M
Result (+)
S
Result (-)
S
ErrorInfo
2277 2278
.req
M
Argument The service-specific parameters of the service request are transmitted in the argument.
2279 2280
ParameterList This parameter specifies the configured identification parameter for a Device.
2281
Parameter type: Record
2282
Record Elements:
2283 2284
VendorID (VID) This parameter specifies the VendorID assigned to a Device (B.1.9)
2285
Data length: 2 octets
2286 2287
DeviceID (DID) This parameter specifies one of the assigned DeviceIDs (B.1.10)
2288
Data length: 3 octets
61131-9/WD V0.5 IEC
– 131 –
Working Draft
2289 2290
FunctionID (FID) This parameter specifies one of the assigned FunctionIDs (see clause B.1.11).
2291
Data length: 2 octets
2292 2293
Result (+): This selection parameter indicates that the service request has been executed successfully.
2294 2295
Result (-): This selection parameter indicates that the service request failed.
2296 2297
ErrorInfo This parameter contains error information to supplement the Result parameter.
2298
Permitted values: STATE_CONFLICT
2299
9.3.2.5
2300 2301
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.
2302
Table 84 – SM_GetDeviceIdent
SM_GetDeviceIdent
Parameter name Argument ParameterList
.req
.cnf
M M
Result (+)
S
Result (-)
S
ErrorInfo
M
2303 2304 2305
Argument The service-specific parameters of the service request are transmitted in the argument.
2306 2307
ParameterList This parameter contains the configured communication parameters of the Device.
2308
Parameter type: Record
2309
Record Elements:
2310 2311
VendorID (VID) This parameter contains the actual VendorID of the Device (B.1.9)
2312
Data length: 2 octets
2313 2314
DeviceID (DID) This parameter contains the actual DeviceID of the Device (B.1.10)
2315
Data length: 3 octets
2316 2317
FunctionID (FID) This parameter contains the actual FunctionID of the Device (B.1.11).
2318
Data length: 2 octets
2319 2320
Result (+): This selection parameter indicates that the service request has been executed successfully.
2321 2322
Result (-): This selection parameter indicates that the service request failed.
2323
ErrorInfo
Working Draft
61131-9/WD V0.5 IEC
– 132 –
2324
This parameter contains error information to supplement the Result parameter.
2325
Permitted values: STATE_CONFLICT
2326
9.3.2.6
2327 2328
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.
2329
Table 85 – SM_SetDeviceMode
SM_SetDeviceMode
Parameter name Argument
.req
.cnf
M
Mode
M
Result (+)
S
Result (-)
S
ErrorInfo
2330 2331 2332 2333 2334
M
Argument The service-specific parameters of the service request are transmitted in the argument. Mode Permitted values: IDLE, SIO
2335 2336
Result (+): This selection parameter indicates that the service request has been executed successfully.
2337 2338
Result (-): This selection parameter indicates that the service request failed.
2339 2340
ErrorInfo This parameter contains error information to supplement the Result parameter.
2341
Permitted values: STATE_CONFLICT
2342
9.3.2.7
2343 2344
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.
2345
Table 86 – SM_DeviceMode
SM_DeviceMode
Parameter name Argument Mode
2346 2347 2348 2349 2350 2351 2352
.ind M M
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
– 133 –
Working Draft
2353
9.3.3
2354
9.3.3.1
2355
The behaviour of the Device is mainly driven by Master messages.
2356
9.3.3.2
2357 2358 2359
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.
SM Device protocol Overview
SM Device state machine
/Initialization SM_SIO_1
SM_Idle_0 SM_DeviceMode_SIO/ T1
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
SM_IdentStartup_4
DL_Mode_PREOPERATE/ T10
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
61131-9/WD V0.5 IEC
– 134 – STATE DESCRIPTION
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.
SM_ComEstablish_2
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.
SM_ComStartup_3
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).
SM_IdentStartup_4
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).
SM_IdentCheck_5
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_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.
SM_Preoperate_7
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.
SM_Operate_8
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.
2364 TRANSITION
SOURCE STATE
TARGET STATE
ACTION
T1
0
1
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)
T2
1
2
The Device is switched to the communication mode by receiving the trigger DL_Mode.ind(STARTUP). PL_SetMode(COMx) SM_DeviceMode(COMSTARTUP)
T3
2,3,4,5,6, 7,8
0
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).
T4
2
3
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
– 135 –
TARGET STATE
Working Draft ACTION
SM_DeviceMode(COMx) T5
3
4
The Device identification phase is entered by receiving the trigger DL_Write.ind(MASTERIDENT). SM_DeviceMode(IDENTSTARTUP)
T6
4
5
The Device identity check phase is entered by receiving the trigger DL_Write.ind(DEVICEIDENT). SM_DeviceMode(IDENTCHANGE)
T7
5
6
The Device compatibility startup phase is entered by receiving the trigger DL_Read.ind( Direct Parameter page 1, 0x02).
T8
6
7
The Device's preoperate phase is entered by receiving the trigger DL_Mode.ind(PREOPERATE). SM_DeviceMode(PREOPERATE)
T9
7
8
The Device's operate phase is entered by receiving the trigger DL_Mode.ind(OPERATE). SM_DeviceMode(OPERATE)
T10
4
7
The Device's preoperate phase is entered by receiving the trigger DL_Mode.ind(PREOPERATE). SM_DeviceMode(PREOPERATE)
T11
3
8
The Device's operate phase is entered by receiving the trigger DL_Mode.ind(OPERATE). SM_DeviceMode(OPERATE)
T12
7
3
The Device's communication startup phase is entered by receiving the trigger DL_Mode.ind(STARTUP). SM_DeviceMode(COM_STARTUP)
T13
8
3
The Device's communication startup phase is entered by receiving the trigger DL_Mode.ind(STARTUP). SM_DeviceMode(COM_STARTUP)
2365 INTERNAL ITEMS COMx
TYPE Variable
DEFINITION Any of COM1, COM2, or COM3 transmission rates
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
61131-9/WD V0.5 IEC
– 136 – DL
AL
SM
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
DL_Write(0x00, PREOPERATE) SM_DeviceMode(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()
From now on: OPERATE state
DL_Write(0x01, MasterCycleTime) DL_Write(0x00, OPERATE) SM_DeviceMode(OPERATE)
2369 2370
Figure 77 – Sequence chart of a regular Device startup
2371 2372 2373 2374
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.
2375 2376
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
– 137 –
DL
Working Draft
SM
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
SM_DeviceMode(IDENTCHANGE)
Device compatibility check: - supported RID - supported DID
SM_SetDeviceCOM(compatible parameter) SM_SetDeviceIdent(compatible DID, FID) DL_Read(Direct Parameter 1)
Master actions: - Check RID, VID, DID, FID (Use case assumes: check OK)
(MinCycleTime, FrameCapability, RID, PDin length, PDout length) DL_Write(0x00, MASTERIDENT)
SM_DeviceMode(IDENTSTARTUP)
DL_Read(Direct Parameter 1) (VID,DID,FID) From now on: PREOPERATE state DL_Write(0x00, PREOPERATE) SM_DeviceMode(PREOPERATE)
...
...
2377 2378
Figure 78 – Sequence chart of a Device startup in compatibility mode
2379 2380 2381 2382
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
61131-9/WD V0.5 IEC
– 138 – DL
SM
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
SM_DeviceMode(IDENTCHANGE)
Device compatibility check: - not supported RID - not supported DID
SM_SetDeviceCOM(supported parameter) SM_SetDeviceIdent(supported DID, FID) DL_Read(Direct Parameter 1)
Master actions: - Check RID, VID, DID, FID (Use case assumes: check DID or RID fails)
(MinCycleTime, FrameCapability, RID, PDin length, PDout length) DL_Write(0x00, MASTERIDENT)
SM_DeviceMode(IDENTSTARTUP)
DL_Read(Direct Parameter 1) (VID,DID,FID)
...
...
2383 2384 2385
Figure 79 – Sequence chart of a Device startup when compatibility fails
61131-9/WD V0.5 IEC
– 139 –
Working Draft
2386
10 Device
2387
10.1
2388
Figure 80 provides an overview of the complete structure and services of a Device.
Overview
Device applications Technology specific application (technology parameter, diagnosis, process data)
System management
DL_Mode
PL_Mode.req
CMD.ind CMD.rsp
PL_WakeUp.ind
PD.ind
AL_PDCycle
AL_NewOutput DL_PDCycle PD.rsp
DL-B
PDValid
FHInfo
CMD.rsp
Device DL-mode handler
Process data handler
CMD.ind
DL_Write
EventFlag
DL_Read
AL_GetOutput
AL_SetInput DL_PDInputUpdate
DL_EventTrigger
DL_Event
DL_Control
DL_ISDUAbort
DL_ISDUTransport
On-request data handler
Line Handler
SIO: DI / DO
Process data objects DL_PDOutputTransport
AL_Event
AL_Control
AL_Write DL_WriteParam
DL_ReadParam
SM_SetDeviceMode
Process Data Exchange (PDE)
On-request data AL objects Application Layer
SM_DeviceMode
SM_SetDeviceComm
SM_SetDevciceIdent
SM_GetDeviceComm
SM_GetDeviceIdent
Event Dispatcher (ED)
AL_Abort
Data Storage (DS)
AL_Read
Parameter Manager (PM)
DL-A
Frame handler PL_Transfer.ind
PL_Transfer.req
SIO: DI / DO
Mode switch Wake-up
Coded switching
Switching signal
Physical layer
2389 2390
Figure 80 – Structure and services of a Device
2391 2392 2393
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
2394 2395
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
2396 2397
Data Storage (DS) mechanism, which optionally uploads or downloads parameters to the Master (see 10.4), and a
2398 2399 2400
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
2401 2402 2403
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).
2404 2405
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
– 140 –
61131-9/WD V0.5 IEC
2406
10.2
2407 2408
The Process Data Exchange unit cyclically transmits and/or receives process data without interference with the on-request data (parameters, commands, and events).
2409 2410 2411 2412
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.
2413 2414 2415
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).
2416 2417 2418
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.
2419
10.3
2420
10.3.1
2421 2422
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).
2423 2424
Mandatory for all Devices are the so-called Direct Parameters in page 1. This page 1 contains common communication and identification parameters (B.1).
2425 2426 2427 2428 2429
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).
2430 2431 2432 2433 2434 2435
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.
2436
10.3.2
2437 2438 2439 2440
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.
2441 2442 2443 2444 2445 2446 2447 2448
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.
2449 2450
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.
Process Data Exchange (PDE)
Parameter Manager (PM) General
Parameter Manager state machine
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
Idle_0
[DownloadStart]/ T16
[DownloadStore]/T2 [Local Parameter]/T3
[DownloadStart]/T7
[DataValid & StoreRequest]/T4
[DownloadBreak]/T8
ValidityCheck_1
Download_2 [DataValid & NotStoreRequest]/T5
SM_DeviceMode_INACTIVE/ T9
[DataInvalid]/T6
[UploadStart]/ T10 SM_DeviceMode_INACTIVE/ T12
[UploadEnd]/ T11
Upload_3
[UploadStart]/T15
[DownloadEnd]/T13 [DownloadStore]/ T14
2453 2454
Figure 81 – The Parameter Manager (PM) state machine
2455 2456
Table 88 shows the state transition tables of the Device Parameter Manager (PM) state machine.
2457
Table 88 – State transition tables of the PM state machine STATE NAME
STATE DESCRIPTION
Idle_0
Waiting on parameter transmission
ValidityCheck_1
Check of consistency and validity of current parameter set.
Download_2
Parameter download active; local parameterization locked (e.g. teach-in)
Upload_3
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")
2458 TRANSITION
SOURCE STATE
TARGET STATE
ACTION
T1
0
1
-
T2
0
1
Set "StoreRequest" (= TRUE)
T3
0
1
Set "StoreRequest" (= TRUE)
T4
1
0
Mark parameter set as valid; send DS_ParUpload.req to DS; enable positive acknowledge of transmission; reset "StoreRequest" (= FALSE)
T5
1
0
Mark parameter set as valid; enable positive acknowledge of transmission
T6
1
0
Mark parameter set as invalid; enable negative acknowledge of transmission; reset "StoreRequest" (= FALSE)
T7
0
2
Lock local parameter access
T8
2
0
Unlock local parameter access; discard parameter buffer
Working Draft TRANSITION
2459
61131-9/WD V0.5 IEC
– 142 –
SOURCE STATE
TARGET STATE
T9
2
0
Unlock local parameter access; discard parameter buffer
T10
0
3
Lock local parameter access
T11
3
0
Unlock local parameter access
T12
3
0
Unlock local parameter access
T13
2
1
Unlock local parameter access
T14
2
1
Unlock local parameter access; set "StoreRequest" (= TRUE)
T15
3
3
Unlock local parameter access; discard parameter buffer
T16
2
2
Hint: A possible second start cannot be blocked.
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
DownloadStore
Bool
SystemCommand "ParamDownloadStore" received, see Table B.8
DataValid
Bool
Positive result of conformity and validity checking
DataInvalid
Bool
Negative result of conformity and validity checking
DownloadStart
Bool
SystemCommand "ParamDownloadStart" received, see Table B.8
DownloadBreak
Bool
SystemCommand "ParamBreak" or "ParamUploadStart" received
DownloadEnd
Bool
SystemCommand "ParamDownloadEnd" received, see Table B.8
StoreRequest
Bool
Flag for a requested Data Storage sequence, i.e. SystemCommand "ParamDownloadStore" received (= TRUE)
NotStoreRequest
Bool
Inverted value of StoreRequest
UploadStart
Bool
SystemCommand "ParamUploadStart" received, see Table B.8
UploadEnd
Bool
SystemCommand "ParamUploadEnd" received, see Table B.8
2460 2461
The Parameter Manager (PM) allows for single parameter (Index and Subindex) as well as for block parameter transmission (entire parameter set).
2462
10.3.3
2463 2464 2465 2466 2467 2468 2469 2470
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.
2471 2472
It is recommended to avoid concurrent access to a parameter via local control elements and SDCI write services at the same point in time.
2473
10.3.4
2474 2475
Sample sequence charts for valid and invalid single parameter changes are described in Figure 82.
Dynamic parameter
Single parameter
61131-9/WD V0.5 IEC Master App
– 143 – Master AL
Working Draft
Device AL
Device App
AL_Write_req(Parameter) SDCI_Message()
AL_Write_ind(Parameter) AL_Write_res(+)
Parameter check result = OK
SDCI_Message()
AL_Write_cnf(+)
Positive result Negative result
AL_Write_req(Parameter) SDCI_Message()
AL_Write_ind(Parameter)
Parameter check failed
AL_Write_res(-) SDCI_Message()
AL_Write_cnf(-)
2476 2477
Figure 82 – Positive and negative parameter checking result
2478 2479 2480 2481
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.
2482
Table 89 – Definitions of parameter checks Parameter check
Definition
Error indication
Access
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)
See C.2.3…C.2.8
Consistency
Check for valid data content of the entire parameter set, testing for interference or correlations between parameters
See C.2.16 and C.2.17
Structure
Check for valid data structure like data size, only complete data structures can be written, for example 2 octets to an UInteger16 data type
See C.2.12 and C.2.13
Validity
Check for valid data content of single parameters, testing for data limits
See C.2.9…C.2.11, C.2.14, C.2.15
2483 2484
10.3.5
2485 2486 2487
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
Block parameter
Working Draft
61131-9/WD V0.5 IEC
– 144 –
2488 2489
parameter changes originating from other sources, for example local parameterization, teachin, etc.
2490 2491
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(+)
Parameter check result = OK
SDCI_Message() DS_ParUpload_req() AL_Write_cnf(+)
Option: Data storage upload request
2492 2493
Figure 83 – Positive block parameter download with Data Storage request
2494 2495 2496
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.
2497 2498 2499 2500
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.
2501
A sample sequence chart for invalid block parameter changes is demonstrated in Figure 84.
61131-9/WD V0.5 IEC Master App
– 145 – Master AL
Working Draft
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(+)
AL_Write_req(SysCommand) (ParamDownloadEnd or ParamDownloadStore)
More parameter sequences as needed
SDCI_Message()
AL_Write_ind(SysCommand) (ParamDownloadEnd or ParamDownloadStore)
Parameter check failed
AL_Write_res(-) SDCI_Message()
AL_Write_cnf(-)
2502 2503
Figure 84 – Negative block parameter download
2504 2505 2506 2507 2508 2509 2510 2511 2512 2513
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.
2514 2515 2516
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.
2517 2518 2519
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
– 146 –
61131-9/WD V0.5 IEC
2520 2521
negative confirmation of the SystemCommand "ParamDownloadStore", the data storage upload request is omitted.
2522
10.3.6
2523 2524 2525
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.
2526
10.3.7
2527 2528 2529 2530 2531
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).
2532
10.4
2533
10.4.1
2534 2535 2536 2537 2538 2539 2540 2541
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.
2542 2543 2544 2545
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.
2546
10.4.2
2547 2548 2549 2550
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".
2551 2552
The Device shall generate an event "DS_UPLOAD_REQ" (Table D.2) only if the parameter set is valid and
2553 2554
parameters assigned for data storage have been changed locally on the Device (for example teach-in, human machine interface, etc.), or
2555
the Device receives a SystemCommand "ParamDownloadStore"
2556 2557
With this event information the Data Storage mechanism of the Master is triggered and initiates a data storage upload sequence.
2558
The state machine in Figure 85 illustrates the Device Data Storage mechanism.
Concurrent parameterization access
Command handling
Data Storage (DS) General
Data Storage state machine
61131-9/WD V0.5 IEC
– 147 –
Working Draft
/Inialization [Unlocked]/ T6
[Locked]/ T1
DSStateCheck_0
DS_ParUpload_ind/ T7
DS_ParUpload_ind/ T2
[Unlocked & not DS_UPLOAD_FLAG]/T3
DSIdle_2
DSLocked_1
[Unlocked & DS_UPLOAD_FLAG]/T4 [Locked]/T5
[TransmissionStart]/T8
[TransmissionEnd]/T9
DSActivity_3
[TranmissionBreak]/T10
2559 2560 2561
Figure 85 – The Data Storage (DS) state machine Table 90 shows the state transition tables of the Device Data Storage (DS) state machine.
2562
Table 90 – State transition table of the Data Storage state machine STATE NAME
2563
STATE DESCRIPTION
DSStateCheck_0
Check activation state after initialization
DSLocked_1
Waiting on data storage state machine to become unlocked
DSIdle_2
Waiting on data storage activities
DSActivity_3
Provide parameter set; local parameterization locked.
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
Set State_Property = "Data storage access locked" (Table B.9)
T2
1
1
Set DS_UPLOAD_FLAG = TRUE (Table B.9)
T3
1
2
Set State_Property = "Inactive" (Table B.9)
T4
1
2
Cast AL_EVENT.req (EventCode: DS_UPLOAD_REQ), Set State_Property = "Inactive" (Table B.9)
T5
2
1
Set State_Property = "Data storage access locked" (Table B.9)
T6
0
2
Set State_Property = "Inactive" (Table B.9)
T7
2
2
Set DS_UPLOAD_FLAG = TRUE (Table B.9), cast AL_EVENT.req (EventCode: DS_UPLOAD_REQ)
T8
2
3
Lock local parameter access, set State_Property = "Upload" or "Download" (Table B.9)
T9
3
2
Set DS_UPLOAD_FLAG = FALSE, unlock local parameter access, Set State_Property = "Inactive" (Table B.9)
T10
3
2
Unlock local parameter access, Set State_Property = "Inactive" (Table B.9)
2564 INTERNAL ITEMS
ACTION
TYPE
DEFINITION
Unlocked
Bool
Data Storage unlocked, see B.2.4
Locked
Bool
Data Storage locked, see B.2.4
DS_ParUpload.ind
Service
Device internal service between PM and DS (Figure 81)
Working Draft
61131-9/WD V0.5 IEC
– 148 –
INTERNAL ITEMS
TYPE
DEFINITION
TransmissionStart
Bool
DS_Command "DS_UploadStart" or "DS_DownloadStart" received, see Table B.9
TransmissionEnd
Bool
DS_Command "DS_UploadEnd" or "DS_DownloadEnd" received, see Table B.9
TransmissionBreak
Bool
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 )
Data storag e requ est inactive
AL_ Write_res(+) SDCI_Message()
AL_ Write_cnf(+)
2568 2569
Figure 86 – Data Storage request message sequence
2570
10.4.3
2571 2572 2573
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.
2574
10.4.4
2575 2576 2577 2578 2579
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.
DS configuration
DS memory space
61131-9/WD V0.5 IEC
– 149 –
Working Draft
2580
10.4.5
2581 2582 2583 2584 2585
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.
2586
10.4.6
2587 2588 2589 2590 2591
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.
2592
10.4.7
2593 2594 2595
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.
2596
10.4.8
2597 2598 2599
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.
2600
10.5
2601 2602 2603 2604 2605 2606 2607 2608 2609
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.
2610 2611 2612
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.
2613 2614 2615
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.
2616
10.6
2617
10.6.1
2618 2619
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.
2620
10.6.2
2621 2622 2623
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
DS Index_List
DS parameter availability
DS without ISDU
DS parameter change indication
Event Dispatcher (ED)
Device features General
Device compatibility
Working Draft
– 150 –
61131-9/WD V0.5 IEC
2624 2625
functional sets or subsets assigned to this DeviceID. Device compatibility support is optional for a Device.
2626
10.6.3
2627 2628 2629 2630
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).
2631
NOTE
2632
10.6.4
2633 2634
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.
2635 2636
NOTE In this case an existing stored parameter set within the Master will be automatically downloaded into the Device after its start-up.
2637 2638 2639
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.
2640
10.6.5
2641 2642 2643 2644 2645
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.
2646
10.6.6
2647 2648 2649 2650
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.
2651
10.6.7
2652 2653 2654 2655 2656
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.
2657
10.6.8
2658 2659 2660 2661
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.
2662
10.6.9
2663 2664 2665
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.
Protocol revision compatibility
A Device (≥ V1.1) operates on a legacy Master (V1.0) according to [13].
Factory settings
Application reset
Device reset
Visual SDCI indication
Parameter access locking
Data storage locking
61131-9/WD V0.5 IEC
– 151 –
Working Draft
2666
10.6.10 Device parameter locking
2667 2668 2669
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.
2670
10.6.11 Device user interface locking
2671 2672 2673
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.
2674
10.6.12 Offset time
2675 2676 2677
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
2678 2679
Data processing of a Device to be synchronized with the Master (port) cycle within certain limits
2680 2681
Data processing of multiple Devices on different Master ports to be synchronized with one another
2682
Data processing of multiple Devices on different Master ports to run with a defined offset
2683
Figure 87 illustrates the timing of messages in respect to the data processing in Devices. tCYC Device specific technology Port (Master)
toffset
Message
Data processing
Message
Message
Device
tframe
2684
toffset
Data processing
Message
tidle
2685
Figure 87 – Cycle timing
2686 2687
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.
2688
10.6.13 Data Storage concept
2689 2690 2691 2692 2693
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.
2694
10.6.14 Block Parameter
2695 2696 2697
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
– 152 –
61131-9/WD V0.5 IEC
2698 2699
exchange of parameters of a Device to be set up at runtime (10.3). The support of this function is optional for a Device.
2700
10.7
2701
10.7.1
2702 2703 2704 2705
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.
2706
10.7.2
2707 2708 2709 2710
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.
2711 2712 2713 2714
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.
2715 2716
See A.1.5 for details on the indication of valid or invalid Process Data via a PDValid flag within cyclic data exchange.
2717
10.7.3
2718 2719 2720 2721 2722
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.
2723 2724
The parameters from the Direct Parameter page cannot be saved and restored via the Data Storage mechanism.
2725
10.7.4
2726 2727
The ISDU communication channel provides a powerful means for the transmission of parameters and commands (B.2).
2728
The following rules shall be considered when using this channel (see Figure 5).
2729 2730
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.
2731 2732
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.
2733 2734
Index 3 cannot be accessed by a PLC application program. The access is limited to the Master application only (Data Storage).
2735 2736
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.
2737
10.7.5
2738 2739 2740
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.
Device design rules and constraints General
Process data
Direct Parameter
ISDU communication channel
Device compatibility
61131-9/WD V0.5 IEC
– 153 –
Working Draft
2741
10.7.6
2742
Table 91 provides an overview of the major protocol constants for Devices.
Protocol constants
2743
Table 91 – Overview of the protocol constants for Devices System variable
References
Values
Definition
ISDU acknowledgement time, for example after a SystemCommand
B.2.2
5 000 ms
Time from reception of an ISDU for example SystemCommand and the beginning of the response message of the Device (Figure 59)
Maximum number of entries in Index List
B.2.3
70
Each entry comprises an Index and a Subindex. 70 entries results in a total of 210 octets.
Preset values for unused or reserved parameters, for example FunctionID
Annex B
0 (if numbers)
Engineering shall set all unused parameters to the preset values.
Wake-up procedure
7.3.2.2
Table 34 and Table 35
Minimum and maximum timings and number of retries
MaxRetry
7.3.3.3
2 Table 38
Maximum number of retries after communication errors
MinCycleTime
A.3.7 and B.1.4
Table A.11 and Table B.3
Device defines its minimum cycle time to aquire input or process output data.
Usable Index range
B.2
Table B.7
This version of the document reserves some areas within the total range of 65 535 Indices.
Errors and warnings
10.9.2
50 ms
An event with MODE "Event appears" shall stay at least for the duration of this time.
Pending errors or warnings
10.9.2
1
Per Device at one point in time
0x00 (if characters)
2744 2745
10.8
2746 2747 2748 2749 2750 2751 2752
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.
2753 2754 2755 2756
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.
2757 2758
The IODD file is mandatory and shall be delivered with each Device (at least accessible via the Internet).
2759
10.9
2760
10.9.1
2761 2762 2763 2764 2765
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.
Device description (IODD)
Device diagnosis Concepts of these for fast the text together
Working Draft
61131-9/WD V0.5 IEC
– 154 –
2766 2767 2768
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.
2769 2770 2771
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.
2772 2773 2774
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]).
2775 2776 2777 2778
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.
2779
Table 92 – Classification of Device diagnosis incidents Diagnosis incident
Appear/ disappear
Single shot
Parameter
Destination
Consumer
Error (fast remedy; standard EventCodes)
yes
-
-
PLC or HMI (fieldbus mapping)
Maintenance and repair personnel
Error (IODD: vendor specific EventCodes; see Table D.1)
yes
-
-
Port Configurator or vendor tool
Vendor service personnel
Error (via Device specific parameters)
-
-
Table B.7
Port Configurator or vendor tool
Vendor service personnel
Warning (fast remedy; standard EventCodes)
yes
-
-
PLC or HMI
Maintenance and repair personnel
Warning (IODD: vendor specific EventCodes; see Table D.1 )
yes
-
Port Configurator or vendor tool
Vendor service personnel
Warning (via Device specific parameters)
-
-
Notification (Standard EventCodes)
-
yes
Port Configurator
Commissioning personnel
Detailed Device status
-
-
Port Configurator or vendor tool
Number of faults via parameter "Error Count"
-
-
B.2.15
Commissioning personnel and vendor service personnel
Device "health" via parameter "Device Status"
-
-
B.2.16,
HMI, Tools such as "Asset Management"
Operator
Table B.7
Table B.12
2780 2781
10.9.2
2782
The following rules apply:
2783
Events of TYPE "Error" shall use the MODEs "Event appears / disappears" (A.6.4)
2784
Events of TYPE "Warning" shall use the MODEs "Event appears / disappears"
2785
Events of TYPE "Notification" shall use the MODE "Event single shot"
2786 2787 2788
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.
Events
61131-9/WD V0.5 IEC
– 155 –
Working Draft
2789 2790 2791
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".
2792
Each Event shall use a static and mode attribute.
2793
Vendor specific Events shall be fixed as an error, warning, or notification.
2794 2795
In order to prevent the diagnosis communication channel (Figure 5) from being flooded, the following rules shall be considered:
2796
Errors or warnings with the same EventCode shall not occur at a high rate.
2797
An event with MODE "Event appears" shall stay for at least 50 ms.
2798 2799
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.
2800
A Device shall not hold more than one pending error or warning at one point in time.
2801
Errors are prioritized against warnings.
2802
10.9.3
2803 2804
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.
2805 2806 2807
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).
Visual indicators
LED off LED on
LED off LED on
LED on
Toff Trep
2808 2809 2810
Figure 88 – Device LED indicator timing Table 93 defines the timing for the LED indicator of Devices.
2811
Table 93 – Timing for LED indicators Timing
Minimum
Typical
Maximum
Unit
T rep
750
1 000
1 250
ms
T off
75
100
150
ms
T off /T rep
7,5
10
12,5
%
2812 2813
10.10 Device connectivity
2814 2815
See 5.5 for the different possibilities of connecting Devices to Master ports and the corresponding cable types as well as the color coding.
2816 2817
Devices can provide additional connections, for example analog outputs for compatibility reasons.
2818
Working Draft
– 156 –
61131-9/WD V0.5 IEC
2819
11 Master
2820
11.1
2821
11.1.1
2822 2823
In 4.2 the domain of the SDCI technology within the automation hierarchy is already illustrated.
2824 2825 2826 2827 2828
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.
Overview Generic model for the system integration of a Master
PLC PLC // Host Host
Parameter server
Fieldbus Fieldbus controller controller Fieldbus integration
Port and Device Configuration Tool (IODD): Port configuration, Device parameterization, Device diagnosis, Identification & maintenance
Fieldbus Fieldbus interface interface Gateway Gateway application application Master Master SDCI
Port 1
Port 2
Engineering/HMI (Fieldbus): Network configuration, Master parameterization, Process data exchange Master/Device diagnosis, Identification & maintenance
Data storage
Port n
Device Device
Device Device
Device Device
Application Application
Application Application
Application Application
Device description
2829 2830
Figure 89 – Generic relationship of SDCI technology and fieldbus technology
2831
11.1.2
2832
Figure 90 provides an overview of the complete structure and the services of a Master.
2833 2834 2835 2836 2837 2838 2839
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
2840 2841
Configuration Manager (CM), which transforms the user configuration assignments into port set-ups;
2842
On-request Data Exchange, which provides for example acyclic parameter access
2843 2844
Data Storage (DS) mechanism, which can be used to save and restore the Device parameters;
Structure and services of a Master
61131-9/WD V0.5 IEC
– 157 –
Working Draft
2845 2846 2847
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;
2848
Process Data Exchange (PDE), building the bridge to upper level automation instruments.
2849
These Master applications provide standard methods/functions common to all Masters.
2850 2851
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.
2852 2853 2854
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)
DL_Mode
System management PL_Mode.req
CMD.cnf
PL_WakeUp.req
AL_PDCycle
AL_SetOutput
DL_PDCycle
DL_PDInputTransport
DL_PDOutputUpdate
DL_EventConf
DL_Event
PDTrig
PD.cnf
DL_Control
CMD.req
PDValid
FHInfo
DL-B ComTrig
Master DL-mode handler
Process data handler
CMD.req
Data Link Layer
CMD.cnf
DL_SetMode
EventFlag.ind
On-request data handler
DL_Write
SIO: DI / DO
Process data objects
PD.req
DL_Read
Coordination
DL_ISDUAbort
DL_ISDUTransport
DL_WriteParam
AL_Read
DL_ReadParam
On-request data AL objects Application Layer
Port x Handler
AL_NewInput
Process Data Exchange AL_GetInput
AL_Event
AL_Abort
AL_Write
Diagnosis Unit
AL_Control
On-request Data Exchange
AL_Read
Data Storage
SM_PortMode
SM_SetPortConfig
SM_GetPortConfig
SM_Operate
Configuration Manager
DL-A
Frame handler PL_Transfer.req
PL_Transfer.ind
SIO: DI / DO
Mode switch Inactive
2855 2856 2857
Wake-up
Coded switching
Physical layer (port)
Figure 90 – Structure and services of a Master Figure 91 shows the relationship of the common Master applications.
Switching signal
Working Draft
61131-9/WD V0.5 IEC
– 158 –
Gateway Gateway application application (configuration, (configuration, parameterization, parameterization, diagnosis, diagnosis, on-request, on-request, and and process process data) data)
DS_Ready DS_Fault
Data Data Storage Storage (DS) (DS)
OD_Unblock
AL_Read
DS_ UPLOAD _REQ
AL_Read
SM-Services
Data
PD_Start
PD_Stop
Process Data interface
Events
DU_Stop
DU_Start
On-request On-request Data Data Exchange Exchange (ODE) (ODE)
AL_Write
Diagnosis interface
Data
OD_Stop
OD_Block
AL_Write
2858
OD_Start
Data DS_Startup
Configuration Configuration Managment Managment (CM) (CM)
On-request Data interface
DS_Delete
Data Storage interface
Operating or Fault
OperatingMode
Start of port and Device
Process Process Data Data Exchange Exchange (PDE) (PDE)
Diagnosis Diagnosis Unit Unit (DU) (DU)
AL_Event AL_Event (response) (Indication) AL_Control AL_PD-Services
2859
Figure 91 – Relationship of the common Master applications
2860 2861 2862
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.
2863
Table 94 – Internal variables and events to control the common Master applications Internal Variable
2864
Definition
DS_Startup
This variable triggers the Data Storage (DS) state machine causing an Upload or Download of Device parameters if required (11.3).
DS_Ready
This variable indicates the Data Storage has been accomplished successfully; operating mode is CFGCOM or AUTOCOM (9.2.2.2)
DS_Fault
This variable indicates the Data Storage has been aborted due to a fault.
DS_Delete
Any verified change of Device configuration leads to a deletion of the stored data set in the Data Storage.
DS_UPLOAD_REQ
This special event "DS_UPLOAD_REQ" from the Device triggers the Data Storage state machine in the Master.
OD_Start
This variable enables On-request Data access via AL_Read and AL_Write.
OD_Stop
This variable indicates that On-request Data access via AL_Read and AL_Write is acknowledged with a negative response to the gateway application.
OD_Block
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.
OD_Unblock
This variable enables On-request Data access via AL_Read or AL_Write.
DU_Start
This variable enables the Diagnosis Unit to propagate remote (Device) or local (Master) events to the gateway application.
DU_Stop
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.
PD_Start
This variable enables the Process Data exchange with the gateway application.
PD_Stop
This variable disables the Process Data exchange with the gateway application.
61131-9/WD V0.5 IEC
– 159 –
Working Draft
2865
11.2
2866
11.2.1
2867 2868 2869 2870
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.
2871 2872 2873
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).
2874 2875 2876 2877
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".
Configuration Manager (CM) General
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
Gateway access to On-request Data disabled
OD_Unblock() DS_Ready() ReadyToOperate() StartOperate() SM_Operate()
Activates all ports
SM_PortMode(OPERATE)
On-request Data Exchange enabled
Operating() OD_Start() PD_Start() DU_Start()
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
Process Data Exchange enabled
Working Draft
– 160 –
61131-9/WD V0.5 IEC
2880 2881
In case of a fault (e.g. RevisionFault, see Figure 66), only the ODE machine will be activated to allow for parameterization.
2882 2883
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.
2884 2885
Several parameters are available for the Configuration Manager to achieve a specific behaviour.
2886
11.2.2
2887
11.2.2.1
2888
One of the following operating modes can be selected. All modes are mandatory.
2889 2890 2891
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.
2892 2893 2894
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.
2895 2896 2897
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.
2898 2899 2900 2901
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).
2902 2903 2904 2905
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".
2906
11.2.2.2
2907
One of the following port cycle modes can be selected. None of the modes is mandatory.
2908 2909
FreeRunning The port cycle timing is not restricted.
2910 2911 2912 2913
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.
2914 2915 2916 2917 2918
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.
Configuration parameter OperatingMode
PortCycle
61131-9/WD V0.5 IEC
– 161 –
Working Draft
Port 1 Port 2 Port 3 Port 4 CycleTime
2919 2920
t
Figure 93 – Ports in MessageSync mode
2921
11.2.2.3
2922 2923
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.
2924
11.2.2.4
2925 2926
This set of parameters contains the rules for the process data mapping between the Device Process Data stream and the gateway Process Data stream.
2927 2928
LenIn This parameter contains the requested length of the Device input ProcessDataIn Bits.
2929 2930
PosIn This parameter contains the offset within the gateway input Process Data stream in Bit.
2931 2932
SrcOffsetIn This parameter contains the offset within the Device input Process Data stream in Bit.
2933 2934
LenOut This parameter contains the requested length of the Device output ProcessDataOut Bits.
2935 2936
PosOut This parameter contains the offset within the gateway output Process Data stream in Bit.
2937 2938
SrcOffsetOut This parameter contains the offset within the Device output Process Data stream in Bit.
2939
11.2.2.5
2940
This set of parameters contains the actual configured Device identification.
2941 2942
VendorID This parameter contains the requested or read vendor specific ID as described in B.1.9.
2943 2944
DeviceID This parameter contains the requested or read Device specific ID as described in B.1.10.
2945
SerialNumber
2946
This parameter contains the requested or read SerialNumber as described in B.2.11.
2947
InspectionLevel
2948
This parameter contains the requested InspectionLevel as described in Table 71.
2949
11.2.2.6
2950
This set of parameter items contains the settings of the Data Storage mechanism.
CycleTime
PDConfig
DeviceIdentification
DataStorageConfig
Working Draft
– 162 –
61131-9/WD V0.5 IEC
2951 2952 2953
ActivationState This parameter contains the requested state of the Data Storage mechanism for this port. The following modes are supported:
2954 2955 2956
Enabled The Data Storage mechanism is active and provides the full functionality as described in 11.3.2.
2957 2958 2959
Disabled The Data Storage mechanism is inactive and the complete parameter set of this port remains stored.
2960 2961 2962
Cleared The Data Storage mechanism is disabled and the stored parameter set of this port is cleared.
2963 2964 2965
DownloadEnable If this configuration is enabled, the Data Storage mechanism is permitted to write data to the connected Device.
2966 2967 2968
UploadEnable If this configuration is enabled, the Data Storage mechanism is permitted to read data from the connected Device.
2969
11.2.3
2970
Figure 94 shows the state machine of the Master configuration manager.
2971 2972
The different states show the steps of necessary commands to establish or maintain communication or the DI or DO state.
2973 2974
Any change of the port configuration can be activated by changing the OperatingMode variable (11.2.2.1).
State machine of the Configuration Manager
61131-9/WD V0.5 IEC
– 163 –
Working Draft
/Initialization [Inactive]/T13
SM_PortMode_yMODE/T10
[DO]/T12
Inactive_0
Port_DIDO_7
[DI]/T11 [AUTOCOM]/ T2
[SDCI]/ T1 SM_Startup_1
PortFault_3
SM_PortMode_xFAULT/ T4 SM_PortMode_CFGCOM/ T3
[DS_Fault]/T7
SM_PortMode_AUTOCOM/ T5
DS_ParamManager_2
[DS_Ready]/ T6 CM_ReadyToOperate_4
[StartOperate]/ T8 WaitingOnOperate_5
SM_PortMode_OPERATE/ T9 Port_Active_6
Key xFAULT: REV_FAULT or COMP_FAULT or SERNUM_FAULT yMODE: INACTIVE or COMLOSS
2975 2976 2977
Figure 94 – State machine of the Configuration Manager Table 95 shows the state transition table of the Configuration Manager state machine.
2978
Table 95 – State transition tables of the Configuration Manager STATE NAME
STATE DESCRIPTION
Inactive_0
Waiting on any of the OperatingMode variables from the gateway application: DO, DI, SDCI, and ScanMode.
SM_Startup_1
Waiting on an established communication or loss of communication or any of the faults REV_FAULT, COMP_FAULT, or SERNUM_FAULT (Figure 66).
DS_ParamManager_2
Waiting on accomplished Data Storage startup. Parameter are downloaded into the Device or uploaded from the Device.
PortFault_3
Device in state PREOPERATE (communicating). However, one of the three faults REV_FAULT, COMP_FAULT, SERNUM_FAULT, or DS_Fault occurred.
CM_ReadytoOperate_4
Port is waiting until the gateway application indicates "StartOperate".
WaitingOnOperate_5
Waiting on SM to switch to OPERATE.
PortActive_6
Port is in OPERATE mode. The gateway application is exchanging Process Data and ready to send or receive On-request Data.
PortDIDO_7
Port is in DI or DO mode. The gateway application is exchanging Process Data (DI or DO).
Working Draft
61131-9/WD V0.5 IEC
– 164 –
2979 TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
SM_SetPortConfig_CFGCOM
T2
0
1
SM_SetPortConfig_AUTOCOM
T3
1
2
DS_Startup: The DS state machine is triggered.
T4
1
3
ConfigFault indication to gateway application (REV_FAULT, COMP_FAULT, or SERNUM_FAULT).
T5
1
2
DS_Startup: The DS state machine is triggered.
T6
2
4
Indication to gateway application: ReadyToOperate
T7
2
3
Data Storage failed. Rollback to previous parameter set.
T8
4
5
SM_Operate.
T9
2980
ACTION
5
6
Indication to gateway application: "Operating" (see Figure 92).
T10
1,2,3,4,5, 6
0
SM_SetPortConfig_INACTIVE. Indication to gateway application: COMLOSS or INACTIVE
T11
0
7
SM_SetPortConfig_DI. Indication to gateway application: DI
T12
0
7
SM_SetPortConfig_DO. Indication to gateway application: DO
T13
7
0
SM_SetPortConfig_INACTIVE.
INTERNAL ITEMS
TYPE
DEFINITION
DS_Ready
Bool
Data Storage sequence (upload, download) accomplished. Port operating mode is SDCI or ScanMode. See Table 94.
DS_Fault
Bool
See Table 94.
StartOperate
Bool
Gateway application causes the port to switch to OPERATE.
SDCI
Bool
One of the OperatingModes (11.2.2.1)
AUTOCOM
Bool
One of the OperatingModes (11.2.2.1)
DI
Bool
One of the OperatingModes (11.2.2.1)
DO
Bool
One of the OperatingModes (11.2.2.1)
2981 2982
11.3
2983
11.3.1
2984 2985 2986 2987 2988
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).
2989
11.3.2
2990
The structure of a Data Storage data object is described in Annex F in Table F.1.
2991 2992 2993 2994 2995
The Master shall always hold the header information (Parameter Checksum, VendorID, and DeviceID) for the purpose of checking and control. The object information (objects 1…n) 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.
2996 2997 2998
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.
Data Storage (DS) Overview
DS data object
61131-9/WD V0.5 IEC
– 165 –
Working Draft
2999
11.3.3
3000 3001 3002
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.
3003
Figure 95 shows the state machine of the Data Storage mechanism.
DS state machine
/Initialization CheckActivationState_0
[DS_Off or DS_Deactivated]/T7
DS_Upload_Req/ T13
[DS_Activated & COM]/ T6
DS_Startup/ T14
Off_3
[DS_Activated & NoCOM]/ T8
DS_Delete/ T10
[DS_Activated]/T1 DS_Off/ T11 DS_Upload_Req/T4
UpDownload_2
WaitingOnDSActivity_1
[DS_Ready]/T3 enex_1
enex_2 DS_Deactivated/ T12
DS_Fault/T5 [DS_Delete]/T9
3004 3005
DS_Startup/T2
Figure 95 – Main state machine of the Data Storage mechanism
3006
Figure 96 shows the submachine of the state "UpDownload_2".
3007 3008
This submachine can be invoked by the Data Storage mechanism or during runtime triggered by a "DS_UPLOAD_REQ" event.
Working Draft
61131-9/WD V0.5 IEC
– 166 – UpDownload_2
[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
[DS_Invalid & Upload_Enable]/ T21
CheckDSValidity_8 [Upload_Fault]/T23
Upload_7 enex_3
[DS_Valid]/ T22
enex_4
CheckChecksum_9
[Checksum_Mismatch & Download_Enable]/ T24 DS_Fault_12
DS_Ready_11 [Checksum_Match]/ T25
Download_10
enex_5
enex_1
[Upload_Done]/ T26
[Download_Fault]/T28
enex_6 [Download_Done]/T27
[DS_Fault]
enex_2 [DS_Ready]
3009 3010
Figure 96 – Submachine "UpDownload_2" of the Data Storage mechanism
3011
Figure 97 shows the submachine of the state "Upload_7".
3012 3013
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 –
Working Draft
Upload_7
ReadParameter_14
[DataIncomplete]/T29
DecomposeIndexList_13
[DataRead]/T30 [DataComplete]/ T34
[COM_ERROR]/ T32
[Device_Error]/ T31
[COM_ERROR]/T33
Upload_Fault_16
[Upload_Fault]
[COM_ERROR]/T35
StoreDataSet_15
enex_3
enex_4
[Upload_Done]
3014 3015
Figure 97 – Data Storage submachine "Upload_7"
3016 3017 3018
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
Device Data Storage
232
AL_Read(DSI: Index 3, Subindex 5, Index_List) Response(Index_List)
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)
... AL_Read(DSI: Index_List, Entry Xn)
Entry Xn
Response(Content of Entry Xn)
Data Storage memory
AL_Read(DSI: Index 3, Subindex 4)
...
Response(Parameter Checksum)
0x00 AL_Write(DSI: Index 3, Subindex 1, DS_UploadEnd) Response(+)
Key DSI = Data Storage Index
Reset DS_UPLOAD_FLAG
3019 3020
Figure 98 – Data Storage upload sequence diagram
3021 3022
Figure 99 shows the submachine of the state "Download_10".
3023
This state machine can be invoked by the Data Storage mechanism.
15
Working Draft
61131-9/WD V0.5 IEC
– 168 – Download_10
WriteParameter_18
[Remaining_Data]/T36
DecomposeSet_17
[Write_done]/T37
[Device_Error]/ T38
[Data_completed]/ T40
[COM_ERROR]/ T39
DownloadDone_19
Download_Fault_20 [COM_ERROR]/ T41
[Download_Fault]
enex_5
enex_6
[Download_Done]
3024 3025
Figure 99 – Data Storage submachine "Download_10"
3026 3027 3028
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
Device Data Storage
AL_Write(DSI: Index 3, Subindex 1, DS_DownloadStart)
232
Response(+)
Header Entry X1
Index 0...65535, 232 octets/index maximum
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 AL_Write(DSI: Index 3, Subindex 1, DS_DownloadEnd)
15
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
– 169 –
STATE NAME
Working Draft
STATE DESCRIPTION expected.
WaitingOnDSActivity_1
Waiting for upload request, Device startup, all changes of activation state independent of the Device communication state.
UpDownload_2
Submachine for up/download actions and checks
Off_3
Data Storage handling switched off or deactivated
SM: CheckIdentity_4
Check Device identification against data set content (Table F.2). No content does not lead to a fault.
SM: CheckSize_5
Check data set size (Index 3, Subindex 3) against available Master storage size
SM: CheckUpload_6
Check for DS_UPLOAD_FLAG within the Data Storage Index (Table B.9)
SM: Upload_7
Submachine for the upload actions
SM: CheckDSValidity_8
Check whether stored data set is valid or invalid
SM: CheckChecksum_9
Check for differences between the data set content and the Device parameter via the "Parameter Checksum" within the Data Storage Index (Table B.9)
SM: Download_10
Submachine for the download actions
SM: DS_Ready_11
Prepare DS_Ready indication to the Configuration Management (CM)
SM: DS_Fault_12
Prepare DS_Fault indication from "Identification_Fault", "SizeCheck_Fault", "Upload_Fault", and "Download_Fault" to the Configuration Management (CM)
SM: Decompose_IL_13
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).
SM: ReadParameter_14
Wait until read content of one entry of the Index List from the Device is accomplished.
SM: StoreDataSet_15
Task of the gateway application: store entire data set according to Table F.1 and Table F.2
SM: Upload_Fault_16
Prepare Upload_Fault indication from "Device_Error" and "COM_ERROR" as input for the higher level indication DS_Fault.
SM: Decompose_Set_17
Write parameter by parameter of the data set into the Device according to Table F.1.
SM: Write_Parameter_18
Wait until write of one parameter of the data set into the Device is accomplished.
SM: Download_Done_19
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.
SM: Download_Fault_20
Prepare Download_Fault indication from "Device_Error" and "COM_ERROR" as input for the higher level indication DS_Fault.
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
2
-
T3
2
1
OD_Unblock; Indicate DS_Ready to CM
T4
1
2
Confirm event "DS_UploadRequest"
T5
2
1
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.
T6
3
2
-
T7
0
3
-
T8
3
1
-
T9
1
1
Clear saved parameter set (Table F.1 and Table F.2)
T10
3
3
Clear saved parameter set (Table F.1 and Table F.2)
T11
1
3
Clear saved parameter set (Table F.1 and Table F.2)
T12
1
3
-
T13
3
3
Confirm event "DS_UploadRequest"; no further action
T14
3
3
DS_Ready to CM
3033
ACTION
Working Draft TRANSITION
3034
61131-9/WD V0.5 IEC
– 170 –
SOURCE STATE
TARGET STATE
T15
4
12
Indicate DS_Fault(Identification_Fault) to the gateway application
T16
4
5
Read "Data Storage Size" according to Table B.9, OD_Block
T17
5
12
Indicate DS_Fault(SizeCheck_Fault) to the gateway application
T18
5
6
Read "DS_UPLOAD_FLAG" according to Table B.9
T19
6
7
Data Storage Index 3, Subindex 1: "DS_UploadStart" (Table B.9)
T20
6
8
-
T21
8
7
Data Storage Index 3, Subindex 1: "DS_UploadStart" ( Table B.9)
T22
8
9
-
T23
7
12
Data Storage Index 3, Subindex 1: "DS_Break" (Table B.9). Indicate "DS_Fault(Upload)" to the gateway application
T24
9
10
Data Storage Index 3, Subindex 1: "DS_DownloadStart" (Table B.9)
T25
9
11
-
T26
7
11
Data Storage Index 3, Subindex 1: "DS_UploadEnd"; read Parameter Checksum (Table B.9)
T27
10
11
Data Storage Index 3, Subindex 1: "DS_DownloadEnd" (Table B.9)
T28
10
12
Data Storage Index 3, Subindex 1: "DS_Break" (Table B.9). Indicate "DS_Fault(Download)" to the gateway application.
T29
13
14
AL_Read (Index List)
T30
14
13
-
T31
14
16
-
T32
14
16
-
T33
13
16
-
T34
13
15
Read "Parameter Checksum" (Table B.9).
T35
15
16
-
T36
17
18
Write parameter via AL_Write
T37
18
17
-
T38
18
20
-
T39
18
20
-
T40
17
19
Read "Parameter Checksum" (Table B.9).
T41
19
20
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
DS_Off
Bool
Data Storage handling switched off, see 11.2.2.6
DS_Deactivated
Bool
Data Storage handling deactivated, see 11.2.2.6
DS_Activated
Bool
Data Storage handling activated, see 11.2.2.6
COM_ERROR
Bool
Error in communication detected
Device_Error
Bool
Access to Index denied, AL_Read or AL_Write.cnf(-) with ErrorCode 0x80
DS_Startup
Variable
Trigger from CM state machine, see Figure 91
NoCOM
Bool
No communication
COM
Bool
Communication OK
DS_UPLOAD_REQ
Event
See Table D.2
UploadEnable
Bool
Data Storage handling configuration, see 11.2.2.6
DownloadEnable
Bool
Data Storage handling configuration, see 11.2.2.6
DataIncomplete
Bool
Still data transmission to perform, parameter list not completed
DataComplete
Bool
All parameter octets transmitted
61131-9/WD V0.5 IEC INTERNAL ITEMS
– 171 – TYPE
Working Draft DEFINITION
SizeCheckPassed
Bool
Required memory space for parameter smaller than available Data Storage space within the Master
IdentificationPassed
Bool
The identification data of the connected Device (DeviceID, VendorID) match the parameter set within the Data Storage.
NoUploadRequested
Bool
DS_UPLOAD_FLAG not set, see Table B.9
DS_Valid
Bool
Valid parameter set available within the Master
DS_Invalid
Bool
No valid parameter set available within the Master
Checksum_Mismatch
Bool
Acquired "Parameter Checksum" from Device does not match the checksum within Data Storage (binary comparison)
Checksum_Match
Bool
Acquired "Parameter Checksum" from Devive matches the checksum within Data Storage (binary comparison)
Download_Done
Bool
Download of parameters accomplished successfully
Upload_Done
Bool
Upload of parameters accomplished successfully
3035 3036
11.3.4
3037
The Device vendor defines the parameters that are part of the Data Storage mechanism.
3038 3039 3040
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.
Parameter selection for Data Storage
3041 3042
11.4
3043 3044
Figure 101 shows the state machine of the Master's On-request Data Exchange. This behaviour is mandatory for a Master.
3045 3046
During an active data transmission of the Data Storage mechanism, all On-request Data requests are blocked.
On-Request Data exchange (ODE)
[ODrequest]/T1
Inactive_0
OD_Start/ T2
OD_Stop/ T3 [ODrequest]/T4
ODactive_1
[ODrequest]/T6 OD_Block/T5
ODblocked_2
OD_Unblock/T7
3047 3048 3049
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.
3050
Table 97 – State transition table of the ODE state machine STATE NAME
STATE DESCRIPTION
Working Draft STATE NAME
3051
61131-9/WD V0.5 IEC
– 172 – STATE DESCRIPTION
Inactive_0
Waiting for activation
ODactive_1
On-request communication active using AL_Read or AL_Write
ODblocked_2
On-request communication blocked
TRANSITION
3052
SOURCE STATE
TARGET STATE
T1
0
0
Access blocked (inactive): indicates "Service not available" to the gateway application
T2
0
1
-
T3
1
0
-
T4
1
1
AL_Read or AL_Write
T5
1
2
-
T6
2
2
Access blocked temporarily: indicates "Service not available" to the gateway application
T7
2
1
-
INTERNAL ITEMS
ACTION
TYPE
DEFINITION
OD
Variable
On-request Data
ODrequest
Variable
On-request Data read or write requested
3053 3054
11.5
3055
11.5.1
3056 3057
Main goal for diagnosis information is to reach an operator in an efficient manner. That means:
3058
No diagnosis information flooding
3059 3060
Report of the root cause of an incident within a Device or within the Master and not subsequent correlated faults
3061 3062
Diagnosis information shall provide information on how to maintain or repair the affected component for fast recovery of the automation system.
3063 3064
Figure 102 demonstrates exemplary the diagnosis information flow through a complete SDCI/fieldbus system.
3065
NOTE
3066 3067 3068 3069 3070 3071 3072 3073
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.
3074 3075 3076
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.
Diagnosis Unit (DU) Generic diagnosis model
The flow can end at the Master/PDCT or be more integrated depending on the fieldbus capabilities.
61131-9/WD V0.5 IEC
– 173 –
Working Draft
Process monitoring (Human Machine Interface - HMI): Fieldbus device diagnosis … SDCI Master/Device diagnosis …
Factory backbone Engineering (Fieldbus): … SDCI Master/Device diagnosis …
Field device description file
PLC PLC // Host Host Fieldbus Fieldbus controller controller Fieldbus
Standard Standardchannel channel diagnosis diagnosis
Fieldbus Fieldbus interface interface Gateway Gateway application application
3077 3078
…
Specific Specificchannel channel diagnosis diagnosis
Specific Specific events events
Port n
Device Device
Device Device
Application Application
Application Application
Device description IODD
Port and Device configuration tool (IODD): … Display SDCI Device diagnosis …
Mapping Mapping Standard Standard events events
Master Master Port 1
Field device description file
IODD defined Events IODD file
Device description IODD
Figure 102 – System overview of SDCI diagnosis information propagation via Events
3079 3080
11.5.2
3081 3082 3083 3084 3085 3086 3087 3088 3089
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.
3090 3091 3092
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.
3093 3094
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.
DU responsibility and Event scheduling
Working Draft
61131-9/WD V0.5 IEC
– 174 – Master Diagnosis Unit
Master AL
Master DL Portx
Device DL
Device AL
DL_Event_ind()
Device App
AL_Event_req()
DL_EventTrigger_req() Step 2: Event propagated to the gateway application
Step 3: Event acknowledged by the gateway application
Step 1: Event x occurs
Message() DL_Event_ind() AL_Event_ind() AL_Event_rsp()
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
Figure 103 – Event scheduling
3097
11.5.3
3098 3099 3100 3101 3102 3103
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.
3104 3105
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.
3106 3107
Figure 104 demonstrates the mechanism of a "multi event transport". It defines the behaviour of the DU in the following steps:
3108 3109
Up to 6 elements of the Event set (AL_Event.ind) are entered into a serializer queue within the DU in ascending order.
3110
The first element of the set is indicated to the gateway application as a "diagnosis report".
3111 3112
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.
3113 3114
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.
3115
Multi Event transport
61131-9/WD V0.5 IEC Master Diagnosis Unit
– 175 – Master AL
Working Draft
Master DL Portx
Device DL
Device AL
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
Figure 104 – Event scheduling (multi event transport)
3118 3119
11.6
3120
11.6.1
3121 3122
The Process Data Exchange provides the transmission of Process Data between the gateway application and the connected Device.
3123 3124 3125
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.
3126
11.6.2
3127 3128
According to 11.2.2.4 the input and output Process Data are mapped to a specific part of the gateway process data stream.
3129 3130
Figure 105 illustrates exemplary the mapping of the Process Data from 3 Master ports to the Gateway Process Data stream.
PD Exchange (PDE) General
Process Data mapping
Working Draft Octet Bit
61131-9/WD V0.5 IEC
– 176 – 5
7
4 07
3 07
2 07
1
0
07
07
0 Gateway Process Data stream
7
07
0 Port 1 : LenIn 16; PosIn 0; SrcOffsetIn 0
7
07
0 Port 2 : LenIn 8; PosIn 16; SrcOffsetIn 4
7
07
0 Port 3 : LenIn 1; PosIn 24; SrcOffsetIn 11
3131 3132
Figure 105 – Process Data mapping from ports to the gateway data stream
3133 3134
11.6.3
3135 3136
The Master informs the Device about the Process Data validity status by sending MasterCommands (see Table B.2) to the Direct Parameter page.
3137 3138
A sample transmission of PDout state from Master application to Device application is shown in the upper section of Figure 106.
3139 3140 3141
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.
3142 3143
Any perturbation while in interleave transmission mode leads to a Process Data invalid indication.
Process Data invalid
61131-9/WD V0.5 IEC Master App
– 177 –
Master AL
Master DL Portx
Working Draft Device DL
Device AL
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)
("PD_Invalid flag")
(PD_INVALD)
(PD_INVALD)
ChecksumStatus() ("PD_Invalid flag")
ChecksumStatus() ("PD_Invalid flag")
...
AL_Control() DL_Control()
ChecksumStatus()
(PD_VALD)
(PD_VALD)
DL_Control() AL_Control()
(PD_VALD)
(PD_VALD)
3144 3145
Figure 106 – Propagation of PD_Invalid from Master to Device
3146 3147
11.7
3148
11.7.1
3149 3150 3151 3152 3153
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.
3154 3155
The PDCT functionality can be integrated partially (navigation, parameter transfer, etc.) or completely into the engineering tool of the particular fieldbus.
3156
11.7.2
3157
Figure 107 shows one example of a PDCT display layout.
Port and Device configuration tool (PDCT) General
Basic layout examples
Working Draft Topology
61131-9/WD V0.5 IEC
– 178 – Identification
Monitoring
Parameter
Diagnosis
Process Data
Toplevel Toplevel … … -- Master Master -- Port Port 1: 1: Device Device AA -- Port Port 2: 2: Device Device B B -- … … -- Port Port n: n: Device Device ZZ
Device Catalog Vendor Vendor Vendor Vendor 11 Vendor Vendor 22 … … Vendor Vendor nn
Device Device Device Device aa Device Device bb Device Device cc … … Device Device zz
Layout Layout of of this this window window defined defined by by the the IODD IODD of of the the connected connected Device Device
3158 3159
Figure 107 – Example 1 of a PDCT display layout
3160 3161 3162
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.
3163
Figure 108 shows another example of a PDCT display layout. Project Tree Toplevel Toplevel … … -- Master Master -- Port Port 1: 1: -- Device Device AA -- Port Port 2: 2: -- Device Device B B -- … … -- Port Port n: n: -- Device Device ZZ
Menu
Parameter
Device Library
Identification Monitoring Parameter Diagnosis Process Data
Layout of this window defined by the IODD of the connected Device
Vendor Vendor 11 -- Device Device aa V1.03 V1.03 -- Device Device bb V1.23 V1.23 -- Device Device cc V2.00 V2.00 -- … … Vendor Vendor 22 -- Device Device aa aa V0.99 V0.99 -- Device Device bb bb V1.1.2 V1.1.2 -- … … … … Vendor Vendor nn -- Device Device xxx xxx V2.3.04 V2.3.04 -- Device Device yyy yyy V1.3 V1.3 -- Device Device zzz zzz V123 V123
3164 3165
Figure 108 – Example 2 of a PDCT display layout
3166
Further information can be retrieved from [2].
3167
11.8
3168
11.8.1
3169 3170 3171 3172
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.
Gateway application General
61131-9/WD V0.5 IEC
– 179 –
Working Draft
3173
11.8.2
3174 3175 3176
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.
3177
11.8.3
3178 3179 3180 3181
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.
3182
11.8.4
3183 3184 3185
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.
3186
11.8.5
3187 3188 3189 3190
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.
3191 3192
This operational mode simplifies the control program due to the omission of configuration before and after an acyclic access.
3193 3194
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.
3195 3196 3197
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.
3198
The following rules shall be observed when implementing DIwithSDCI:
3199 3200
The DI signal of the Device is not valid during the acyclic access of the gateway application.
3201 3202 3203
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.
3204 3205
The access will consume more time due to establishing communication and fallback procedures including Data Storage.
3206 3207
The InspectionLevel shall at least comprise TYPE_COMP in order to detect an illegal Device.
3208 3209
The following state diagram in Figure 109 shows the individual states for the virtual operational mode DIwithSDCI.
Changing Device configuration including Data Storage
Parameter server (recipe)
Anonymous parameters
Virtual port mode DIwithSDCI
Working Draft
61131-9/WD V0.5 IEC
– 180 –
/Initialization Idle_0 Service_rsp/ T10 Service_req/ T1
Check_Config_1
[InspLevel_LOW]/ T2
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
Figure 109 – Virtual port mode "DIwithSDCI"
3212
Table 98 shows the states and transitions of the virtual port mode "DIwithSDCI".
3213
Table 98 – State transitions of the state machine "DIwithSDCI" STATE NAME
STATE DESCRIPTION
Inactive_0
For the higher level control program the port is configured for the operational mode DIwithSDCI and waits on service requests.
Check_Config_1
Within this state the InspectionLevel of the port is checked for a sufficient level.
DwS_StartUp_2
Within this state a complete startup until the PREOPERATE state is performed. This can include Data Storage and Event handling.
DwS_Await_Resp_3
Wait on responses (AL-Read.rsp or AL-Write.rsp).
DwS_FallBack_4
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.
Build_ServiceResp_5
The service response (positive or negative) will be created to finalize the service to the higher level control program.
TRANSITION
SOURCE STATE
TARGET STATE
T1
0
1
-
T2
1
5
-
T3
1
2
SM_SetPortConfig (to SDCI)
T4
2
5
SM_SetPortConfig (to DI)
T5
2
3
Start Service (AL_Read.req oder AL_Write.req)
T6
3
5
SM_SetPortConfig (to DI)
T7
3
4
-
T8
4
5
SM_SetPortConfig (to DI)
3214
ACTION
61131-9/WD V0.5 IEC TRANSITION
3215
SOURCE STATE
TARGET STATE
T9
4
5
SM_SetPortConfig (to DI)
T10
5
0
-
INTERNAL ITEMS
3216
– 181 –
Working Draft ACTION
TYPE
DEFINITION
InspLevel_LOW
Bool
The necessary InspectionLevel is not configured in order to detect the correct Device.
InspLevel_OK
Bool
The necessary InspectionLevel is configured to detect the correct Device.
PreOperate
Bool
State PREOPERATE is established
Service_complete
Bool
The gateway application received AL_Read.rsp or AL_Write.rsp
Fallback_OK
Bool
Fallback has been accomplished successfully
Error_any
Bool
Any error will quit this state
Working Draft 3217 3218 3219
61131-9/WD V0.5 IEC
– 182 –
Annex A (normative) Codings, timing constraints, and errors
3220
A.1
3221
A.1.1
3222 3223
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.
3224
A.1.2
3225 3226 3227 3228
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.
General structure and encoding of F-sequences Overview
F-sequence control (FC)
R/W
Communication channel
Address
3229 3230
Figure A.1 – F-sequence control
3231
Bit 0 to 4: Address
3232 3233 3234 3235 3236
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).
3237
Bit 5 to 6: Communication channel
3238 3239
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.
3240
Table A.1 – Values of communication channel Value
Definition
0
Process
1
Page
2
Diagnosis
3
ISDU
3241
Bit 7: R/W
3242 3243 3244 3245
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.
3246
Table A.2 – Values of R/W Value
Definition
0
Write access
1
Read access
61131-9/WD V0.5 IEC
– 183 –
Working Draft
3247 3248 3249
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.
3250
A.1.3
3251 3252
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.
Checksum / F-sequence type (CKT)
F-sequence type
Checksum
3253 3254
Figure A.2 – Checksum/F-sequence type octet
3255
Bit 0 to 5: Checksum
3256 3257
These bits contain a 6 bit message checksum to ensure data integrity, see also A.1.6 and H.1.
3258
Bit 6 to 7: F-sequence type
3259 3260 3261
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.
3262
Table A.3 – Values of F-sequence types Value
Definition
0
Type 0
1
Type 1
2
Type 2 (see NOTE)
3
reserved
NOTE Subtypes depending on process data configuration and process data direction
3263 3264
A.1.4
3265 3266 3267 3268
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).
3269
Table A.4 – Data types for user data
User data (PD or OD)
Data type
Reference
BooleanT
See E.2
UIntegerT
See E.2.3
IntegerT
See E.2.4
StringT
See E.2.6
OctetStringT
See E.2.7
Float32T
See E.2.5
TimeT
See E.2.8
(IEC 61158-6)
TimeSpanT
See E.2.9
(IEC 61158-6)
Working Draft
– 184 –
61131-9/WD V0.5 IEC
3270
The detailed coding of the data types can be found in Annex E.
3271
A.1.5
3272 3273 3274
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.
Checksum / status (CKS)
Event flag
PD invalid
Checksum
3275 3276
Figure A.3 – Checksum/status octet
3277
Bit 0 to 5: Checksum
3278 3279
These bits contain a 6 bit checksum to ensure data integrity of the reply message. See also A.1.6 and H.1.
3280
Bit 6: PD invalid
3281 3282
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.
3283 3284
This flag shall be used for Devices with input process data. Devices with output process data shall always indicate process data valid.
3285 3286
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.
3287
Table A.5 – Values of PD invalid Value
Definition
0
Process data valid
1
Process data invalid
3288 3289
Bit 7: Event flag
3290 3291 3292 3293
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.
3294
Table A.6 – Values of the event flag Value
Definition
0
No event
1
Event
3295 3296
A.1.6
3297 3298 3299 3300 3301
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
Calculation of the checksum
61131-9/WD V0.5 IEC
– 185 –
Working Draft
3302 3303 3304 3305 3306
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).
3307 3308
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
FC CKT
+
+ Checksum 8
XOR processing
... Message
Octet n
+
+
+
+
Checksum 6
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
(A.1)
D2 6 = D5 8 xor D4 8 D1 6 = D3 8 xor D2 8 D0 6 = D1 8 xor D0 8 3312 3313
A.2
3314
A.2.1
3315 3316 3317
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.
3318 3319 3320 3321 3322
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.
3323
A.2.2
3324
F-sequence TYPE_0 is mandatory for all Devices.
3325 3326
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.
F-sequence types Overview
F-sequence TYPE_0
Working Draft
61131-9/WD V0.5 IEC
– 186 – TYPE TYPE 00 FC
Master read message
CKT OD
Device reply message
FC
Master write message
CKT
CKS
OD CKS
Device reply message
3327 3328
Figure A.5 – F-sequence TYPE_0
3329
A.2.3
3330
F-sequence TYPE_1_x is optional for all Devices.
3331
F-sequence TYPE_1_1 is illustrated in Figure A.6.
F-sequence TYPE_1_x
TYPE_1_1 TYPE_1_1 Master read message
FC
CKT PD0
Device reply message
Master write message
3332
FC
CKT
PD0
PD1
CKS
PD1
Device reply message
CKS
3333
Figure A.6 – F-sequence TYPE_1_1
3334 3335
Two octets of process data are read or written per cycle. Address (bit offset) belongs to the process communication channel (A.2.1).
3336 3337
In case of interleave mode (7.3.4.2) and odd-numbered PD length the remaining octets within the frames are padded with 0x00.
3338 3339
F-sequence TYPE_1_2 is illustrated in Figure A.7. Two octets of on-request data are read or written per cycle.
3340 3341 3342
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
– 187 –
Working Draft
TYPE_1_2 TYPE_1_2 Master read message
FC
CKT OD0
Device reply message
Master write message
FC
CKT
OD0
OD1
OD1 CKS
Device reply message
3343
CKS
3344
Figure A.7 – F-sequence TYPE_1_2
3345 3346
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.
3347 3348 3349
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
FC
CKT OD0
Device reply message
Master write message Device reply message
3350 3351
FC
CKT
OD0
ODm-1
CKS
ODm-1 CKS
Figure A.8 – F-sequence TYPE_1_V
3352
A.2.4
3353 3354 3355 3356 3357 3358 3359
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.
3360 3361
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.
F-sequence TYPE_2_x
Working Draft
61131-9/WD V0.5 IEC
– 188 – TYPE_2_1 TYPE_2_1 FC
Master read message
CKT OD
Device reply message
FC
Master write message
3362
CKT
CKS
PD
OD PD
Device reply message
CKS
3363
Figure A.9 – F-sequence TYPE_2_1
3364 3365
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
FC
CKT OD
Device reply message
Master write message
3366
FC
CKT
PD0
PD1
CKS
OD PD0
Device reply message
PD1
CKS
3367
Figure A.10 – F-sequence TYPE_2_2
3368 3369
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
FC
CKT
PD OD
Device reply message
Master write message
3370
FC
CKT
PD
CKS
OD
Device reply message
CKS
3371
Figure A.11 – F-sequence TYPE_2_3
3372 3373
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
– 189 –
Working Draft
TYPE_2_4 TYPE_2_4 FC
Master read message
CKT
PD0
PD1 OD
Device reply message
FC
Master write message
3374
CKT
PD0
PD1
CKS
OD CKS
Device reply message
3375
Figure A.12 – F-sequence TYPE_2_4
3376 3377
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 FC
Master read message
CKT
PD OD
Device reply message
FC
Master write message
3378
CKT
PD
PD
CKS
PD
CKS
OD
Device reply message
3379
Figure A.13 – F-sequence TYPE_2_5
3380 3381
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
FC
CKT
PD0
PD1 OD
Device reply message
Master write message
3382
Device reply message
FC
CKT
PD0
PD1
PD0
PD1
CKS
PD0
PD1
CKS
OD
3383
Figure A.14 – F-sequence TYPE_2_6
3384 3385 3386 3387 3388
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
61131-9/WD V0.5 IEC
– 190 –
TYPE_2_V TYPE_2_V Master read message
FC
CKT
PD0
PDn-1 OD0
Device reply message
Master write message
FC
CKT
PD0
PDn-1
OD0
ODm-1
PD0
PDk-1
CKS
PD0
PDk-1
CKS
ODm-1
Device reply message
3389 3390
Figure A.15 – F-sequence TYPE_2_V
3391 3392 3393
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".
3394
A.2.5
3395
F-sequence type 3 is reserved and shall not be used.
3396
A.2.6
3397 3398
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.
3399
Table A.7 – F-sequence types for the STARTUP mode
F-sequence type 3
F-sequence type usage for STARTUP, PREOPERATE and OPERATE modes
F-sequence Capability n/a
On-request data
F-sequence type
Minimum cycle time
Octets 1
T BIT TYPE_0
100
3400 3401 3402
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.
3403
Table A.8 – F-sequence types for the PREOPERATE mode F-sequence Capability
On-request data
F-sequence type
Minimum cycle time
Octets
T BIT
0
1
TYPE_0
100
1
2
TYPE_1_2
100
2
8
TYPE_1_V
210
3
32
TYPE_1_V
550
NOTE
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
On-request Data
Process Data (PD)
Octets
PDin
F-sequence type
PDout
V1.0 [13]
0
1
0
0
TYPE_0
1
2
0
0
TYPE_1_2
*
2
3…32 octets
0…32 octets
TYPE_1_1/1_2 interleaved
*
2
0…32 octets
3…32 octets
TYPE_1_1/1_2 interleaved
*
1
1…8 bit
0
TYPE_2_1
*
1
9…16 bit
0
TYPE_2_2
*
1
0
1…8 bit
TYPE_2_3
*
1
0
9…16 bit
TYPE_2_4
*
1
1…8 bit
1…8 bit
TYPE_2_5
Key
* = don't care
3409 3410 3411 3412
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).
3413
Table A.10 – F-sequence types for the OPERATE mode F-sequence Capability
On-request Data
Process Data (PD)
Octets
PDin
F-sequence type
PDout
0
1
0
0
TYPE_0
1
2
0
0
TYPE_1_2
6
8
0
0
TYPE_1_V
7
32
0
0
TYPE_1_V
0
2
3…32 octets
0…32 octets
TYPE_1_1/1_2 interleaved (see NOTE)
0
2
0…32 octets
3…32 octets
TYPE_1_1/1_2 interleaved (see NOTE)
0
1
1…8 bit
0
TYPE_2_1
0
1
9…16 bit
0
TYPE_2_2
0
1
0
1…8 bit
TYPE_2_3
0
1
0
9…16 bit
TYPE_2_4
0
1
1…8 bit
1…8 bit
TYPE_2_5
0
1
9…16 bit
1…16 bit
TYPE_2_6
0
1
1…16 bit
9…16 bit
TYPE_2_6
4
1
0…32 octets
3…32 octets
TYPE_2_V
4
1
3…32 octets
0…32 octets
TYPE_2_V
5
2
>0 bit, octets
≥0 bit, octets
TYPE_2_V
5
2
≥0 bit, octets
>0 bit, octets
TYPE_2_V
6
8
>0 bit, octets
≥0 bit, octets
TYPE_2_V
6
8
≥0 bit, octets
>0 bit, octets
TYPE_2_V
7
32
>0 bit, octets
≥0 bit, octets
TYPE_2_V
7
32
≥0 bit, octets
>0 bit, octets
TYPE_2_V
Working Draft F-sequence Capability
61131-9/WD V0.5 IEC
– 192 – On-request Data Octets
Process Data (PD) PDin
F-sequence type
PDout
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
A.3
3416
A.3.1
3417 3418
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 ).
3419
A.3.2
3420 3421
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).
Timing constraints General
Bit time
T BIT = 1/(transmission rate)
(A.2)
3422
Values for T BIT are specified in Table 7.
3423
A.3.3
3424 3425 3426
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).
Character transmission delay of Master (ports)
0 ≤ t 1 ≤ 1 T BIT
(A.3)
3427
A.3.4
3428 3429 3430
The Device’s 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).
Character transmission delay of Devices
0 ≤ t 2 ≤ 3 T BIT
(A.4)
3431
A.3.5
3432 3433 3434 3435
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).
Response time of Devices
1 T BIT ≤ t A ≤ 10 T BIT
(A.5)
3436
A.3.6
3437 3438
Communication between a port and and its associated Device takes place in a fixed schedule, called the F-sequence time (A.6).
F-sequence time
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
– 193 –
Working Draft
3439 3440 3441
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.
3442 3443
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
t1
UART character
t1
UART character
Device
UART character
t2
UART character
t2
tA tF-sequence
3444 3445
Figure A.16 – F-sequence timing
3446
A.3.7
3447 3448
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.
Cycle time
t CYC = t
F-sequence
+ t idle
(A.7)
3449 3450 3451
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.
3452 3453 3454
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.
3455
Table A.11 – Recommended MinCycleTimes Transmission rate
t CYC
COM1
18,0 ms
COM2
2,3 ms
COM3
0,4 ms
3456
A.3.8
3457 3458 3459
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).
3460
NOTE
Idle time
The idle time shall be long enough for the Device to become ready to receive the next message.
Working Draft
– 194 –
61131-9/WD V0.5 IEC
3461
A.4
3462
A.4.1
3463
A.4.1.1
3464 3465 3466 3467
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.
3468 3469
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.
3470
A.4.1.2
3471 3472 3473
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.
3474
Remedy: See A.4.1.1.
3475
A.4.2
3476 3477
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.
3478
Remedy: Retries are possible. See 7.3.2.1 for details.
3479
A.4.3
3480
A.4.3.1
3481 3482
The checksum mechanism is described in A.1.6. Any checksum error leads to an error processing.
3483
Remedy: See A.4.1.1.
3484
A.4.3.2
3485 3486
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.
3487
Remedy: See A.4.1.1.
3488
A.4.3.3
3489 3490
A collision occurs whenever the Master and Device are sending simultaneously due to an error. This error is interpreted as a faulty F-sequence.
3491
Remedy: See A.4.1.1.
3492
A.4.4
3493 3494
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).
3495
Remedy: Abort of service with ErrorType information (Annex C).
Errors and remedies UART errors Parity errors
UART framing errors
Wake-up errors
Transmission errors Checksum errors
Timeout errors
Collisions
Protocol errors
61131-9/WD V0.5 IEC
– 195 –
Working Draft
3496
A.5
3497
A.5.1
3498 3499
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.
3500
A.5.2
General structure and encoding of ISDUs Overview
Service Service
Length
3501 3502
Figure A.17 – Service octet
3503 3504
Bits 0 to 3: Length The encoding of the nibble Length of the ISDU is defined in Table A.14 .
3505 3506
Bits 4 to 7: Service The encoding of the nibble Service of the ISDU is defined in Table A.12.
3507
All other elements of the structure defined in 7.3.6.1 are transmitted as independent octets.
3508
Table A.12 – Definition of the nibble "Service" Service (binary)
Index format
Definition Master
Device
0000
No Service
No Service
n/a
0001
Write Request
Reserved
8-bit Index
0010
Write Request
Reserved
8-bit Index and Subindex
0011
Write Request
Reserved
16-bit Index and Subindex
0100
Reserved
Write Response (-)
none
0101
Reserved
Write Response (+)
none
0110
Reserved
Reserved
0111
Reserved
Reserved
1000
Reserved
Reserved
1001
Read Request
Reserved
8-bit Index
1010
Read Request
Reserved
8-bit Index and Subindex
1011
Read Request
Reserved
16-bit Index and Subindex
1100
Reserved
Read Response (-)
none
1101
Reserved
Read Response (+)
none
1110
Reserved
Reserved
1111
Reserved
Reserved
3509 3510
Table A.13 defines the syntax of the ISDUs. ErrorType can be found in Annex C.
Working Draft
61131-9/WD V0.5 IEC
– 196 –
3511
Table A.13 – ISDU syntax ISDU name
ISDU structure
Write Request
{Service(0x1), LEN, Index, [Data*], CHKPDU} ^ {Service(0x2), LEN, Index, Subindex, [Data*], CHKPDU} ^ {Service(0x3), LEN, Index, Index, Subindex, [Data*], CHKPDU}
Write Response (+)
Service(0x5), Length(0x2), CHKPDU
Write Response (-)
Service(0x4), Length(0x4), ErrorType, CHKPDU
Read Request
{Service(0x9), Length(0x3), Index, CHKPDU} ^ {Service(0xA), Length(0x4), Index, Subindex, CHKPDU} ^ {Service(0xB), Length(0x5), Index, Index, Subindex, CHKPDU}
Read Response (+)
Service(0xD), LEN, [Data*], CHKPDU
Read Response (-)
Service(0xC), Length(0x4), ErrorType, CHKPDU
Key LEN = {Length(0x1), ExtLength} ^ {Length}
3512 3513
A.5.3
3514 3515 3516 3517
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.
3518
Table A.14 – Definition of nibble Length and octet ExtLength
Extended length (ExtLength)
Service
Length
ExtLength
Definition
0
0
n/a
No service, ISDU length is 1. Protocol use.
0
1
n/a
Device busy, ISDU length is 1. Protocol use.
0
2 to 15
n/a
Reserved and shall not be used
1 to 15
0
n/a
Reserved and shall not be used
1 to 15
1
0 to 16
Reserved and shall not be used
1 to 15
1
17 to 238
1 to 15
1
239 to 255
1 to 15
2 to 15
n/a
Length of ISDU in "ExtLength" Reserved and shall not be used Length of ISDU
3519 3520
A.5.4
3521 3522 3523
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.
3524 3525
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.
3526 3527 3528
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).
3529 3530
Table A.15 shows the Index formats used in the ISDU depending on the parameters transmitted.
Index and Subindex
61131-9/WD V0.5 IEC
– 197 –
3531
Working Draft
Table A.15 – Use of Index formats Index
Subindex
Index format of ISDU
0 to 255
0
0 to 255
1 to 255
8 bit Index and 8 bit Subindex
256 to 65 535
0 to 255
16-bit Index and 8 bit Subindex (see NOTE)
8 bit Index
NOTE See B.2.1 for constraints on the Index range
3532 3533
A.5.5
3534 3535 3536
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.
3537
A.5.6
3538 3539 3540
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).
Data
Check ISDU (CHKPDU)
Receiver
Sender Service
Service
Length
Length
ExtLength
+
+
Index
+
Subindex
+
Subindex
+
Data 1
+
Data 1
+
...
+
...
+
Data n
+
Data n
+
1. CHKPDU = "0" 2. CHKPDU = Checksum
+
CHKPDU = Checksum
+
ExtLength
+
Index
Prior to sending
3541
XOR
Checksum Checksum
XOR
Result Result == "0", "0", otherwise otherwise perturbed perturbed bits bits
3542
Figure A.18 – Check of ISDU integrity via CHKPDU
3543 3544 3545
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.
3546
A.5.7
3547 3548
Figure A.19 illustrates typical examples of request formats for ISDUs, which are explained in the following sections.
ISDU examples
Working Draft Request example 1 Service
Request example 2
0101
Service
Request example 3
0110
Service
Request example 4
0111
Service
0001
Index
Index
Index
Data 1 (MSO)
Subindex
Index
Index
Data 2 (LSO)
Data 1
Subindex
Data 1
Data 2
Data 1
Data 2
CHKPDU
Data 2
...
CHKPDU
...
CHKPDU 8 Bit Index
8 Bit Index and Subindex
3549
61131-9/WD V0.5 IEC
– 198 –
ExtLength (n)
Request example 5 0000
0000
1)
"Idle" request
Data (n-4)
16 Bit Index and Subindex
CHKPDU
1) Overall ISDU ExtLength = n (1 to 238); Length = 1 ("0001")
3550
Figure A.19 – Examples of request formats for ISDUs
3551 3552 3553 3554
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").
3555 3556 3557
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").
3558 3559 3560
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").
3561 3562 3563
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".
3564 3565
The ISDU request "Idle" in example 5 should be used as a "keep alive" message in order to detect any communication interrupts.
3566 3567
Figure A.20 illustrates typical examples of response ISDUs, which are explained in the following sections Response example 1 Service
0010 1)
CHKPDU
Response example 2 Service
0100
Data 1 (MSO)
Response example 3 Service
Response example 4
0001
ExtLength (n)
Data 2 (LSO)
Data 1
CHKPDU
Data 2
0000
0001
2)
"Busy" response
...
3568
1) Minimum length = 2 ("0010") 2) Overall ISDU ExtLength = n (17 to 238); Length = 1 ("0001")
... Data (n-3) CHKPDU
3569
Figure A.20 – Examples of response ISDUs
3570
The ISDU response in example 1 shows the minimum value 2 for the Length element ("0010").
61131-9/WD V0.5 IEC
– 199 –
Working Draft
3571 3572 3573
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.
3574 3575 3576
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".
3577 3578
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.
3579 3580
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
0011
Read.res (+, Data) 1101
0100
Read.res (-, Error) or
1100
0100
Index
Data 1 (MSO)
ErrorCode
CHKPDU
Data 2 (LSO)
AdditionalCode
CHKPDU
CHKPDU
Write.req (Index, Data) 0010
0110 Index
Write.res (+) 0101
Write.res (-, Error) 0010
CHKPDU
or
0100
0100
ErrorCode
Subindex
AdditionalCode
Data 1 (MSO)
CHKPDU
Data 2 (LSO) CHKPDU
3581 3582
Figure A.21 – Examples of read and write request ISDUs
3583 3584 3585 3586 3587
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).
3588 3589 3590 3591 3592
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).
3593
A.6
3594
A.6.1
3595 3596 3597
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.
General structure and encoding of events General
Working Draft
61131-9/WD V0.5 IEC
– 200 –
3598
A.6.2
3599 3600 3601
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.
StatusCode type 1 (no details)
Details
PD Invalid
Reserv.
Event Code (type 1)
0
3602 3603
Figure A.22 – Structure of StatusCode type 1
3604 3605 3606
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.
3607
Table A.16 – Mapping of EventCodes (type 1) EventCode (type 1)
Instance
Type
Mode
****1
0xFF80
Application
Notification
Event single shot
***1*
0xFF80
Application
Warning
Event single shot
**1**
0x6320
Application
Error
Event single shot
*1***
0xFF80
Application
Error
Event single shot
1****
0xFF10
Application
Error
Event single shot
Key * type 2
3608 3609 3610
EventCode (type2)
Don't care See Table D.1 and Table D.2
Bit 5: Reserved This bit is reserved and shall be set to zero in StatusCode type 1.
3611 3612
Bit 6: Reserved
3613 3614 3615
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.
3616
A.6.3
3617
Figure A.23 shows the structure of the StatusCode type 2.
NOTE
This bit is used in V1.0 for PDinvalid indication
StatusCode type 2 (with details)
Details Reserv.
Activated events
1
3618 3619
Figure A.23 – Structure of StatusCode type 2
3620 3621 3622 3623 3624
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 –
Working Draft 5
Details Reserv.
Activated events
0
1
StatusCode (type 2)
EventQualifier and EventCode 1 EventQualifier and EventCode 2 EventQualifier and EventCode 3 EventQualifier and EventCode 4 EventQualifier and EventCode 5 EventQualifier and EventCode 6
3625 3626
Figure A.24 – Indication of activated events
3627 3628
Bit 6: Reserved This bit is reserved and shall be set to zero.
3629
NOTE
3630 3631 3632
Bit 7: Event Details This bit indicates that detailed event information is available. It shall always be set in StatusCode type 2.
3633
A.6.4
3634
The EventQualifier is illustrated in Figure A.25.
This bit is used in the legacy protocol version V1.0 [13] for PDinvalid indication
EventQualifier
MODE
TYPE
SOURCE
INSTANCE
3635 3636
Figure A.25 – Structure of the EventQualifier
3637 3638 3639
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.
3640 3641
Table A.17 – Values of INSTANCE Value
Definition
0
Unknown
1
PL
2
DL
3
AL
4
Application
5 to 7
Reserved
Working Draft
– 202 –
61131-9/WD V0.5 IEC
3642 3643 3644 3645
Bit 3: SOURCE This bit indicates the source of the Event. Permissible values for SOURCE are listed in Table A.18.
3646
Table A.18 – Values of SOURCE
3647 3648 3649
Value
Definition
0
Device application (remote)
1
Master application (local)
Bits 4 to 5: TYPE These bits indicate the event category. Permissible values for TYPE are listed in Table A.19.
3650
Table A.19 – Values of TYPE Value
3651 3652 3653
Definition
0
Reserved
1
Notification
2
Warning
3
Error
Bits 6 to 7: MODE These bits indicate the event mode. Permissible values for MODE are listed in Table A.20.
3654
Table A.20 – Values of MODE Value
Definition
0
reserved
1
Event single shot
2
Event disappears
3
Event appears
3655 3656
A.6.5
3657 3658
The EventCode entry contains the identifier of an actual event. Permissible values for EventCode are listed in Annex D.
EventCode
61131-9/WD V0.5 IEC
– 203 –
3659 3660 3661
Working Draft
Annex B (normative) Parameter and commands
3662
B.1
3663
B.1.1
3664 3665 3666 3667 3668
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.
3669 3670
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 1 and 2 Overview
Direct parameter Page 2: Device (individual or profile)
Page 1: System and predefined parameters and controls (fixed)
Device specific 0x10 … 0x1F
Application control 0x0F Identification 0x07 … 0x0E Communication control 0x00 … 0x06
3671 3672
Figure B.1 – Classification and mapping of direct parameters
3673
Page 1 ranges from 0x00 to 0x0F. It comprises the following categories of parameters:
3674
Communication control
3675
Identification parameter
3676
Application control
3677 3678 3679
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.
3680 3681 3682 3683 3684
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.
3685 3686
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
61131-9/WD V0.5 IEC
– 204 –
3687 3688
supported optional parameters). The Device shall ignore a write access to not implemented parameters.
3689
Table B.1 – Direct parameter page 1 and 2 Address
Parameter name
Access
Implementation /reference
Description
Direct parameter page 1 0x00
MasterCommand
W
Mandatory/ B.1.2
Master command to switch to operating states (see NOTE)
0x01
MasterCycleTime
R/W
Mandatory/ B.1.3
Actual cycle duration used by the Master to address the Device. Can be used as a parameter to monitor process data transfer.
0x02
MinCycleTime
R
Mandatory/ B.1.4
Minimum cycle duration supported by a Device. This is a performance feature of the Device and depends on its technology and implementation.
0x03
F-sequence Capability
R
Mandatory/ B.1.5
Information about implemented options related to F-sequences and physical configuration
0x04
RevisionID
R/W
Mandatory/ B.1.6
ID of the used protocol version for implementation (shall be set to 0x11)
0x05
ProcessDataIn
R
Mandatory/ B.1.7
Number and structure of input data (process data from Device to Master)
0x06
ProcessDataOut
R
Mandatory/ B.1.8
Number and structure of output data (process data from Master to Device)
0x07
VendorID 1 (MSB)
R
Mandatory/ B.1.9
Unique vendor identification (see Annex K for support)
0x08
VendorID 2 (LSB)
0x09
DeviceID 1 (Octet 2,MSB)
R/W
Mandatory/ B.1.10
Unique Device identification allocated by a vendor
0x0A
DeviceID 2 (Octet 1)
0x0B
DeviceID 3 (Ocet 0, LSB)
0x0C
FunctionID 1 (MSB)
R
B.1.11
Reserved (Engineering shall set both octets to "0x00")
0x0D
FunctionID 2 (LSB) R
reserved
W
Optional/ B.1.12
Command interface for end user applications only and Devices without ISDU support (see NOTE)
Optional
Optional/ B.1.13
Device specific parameters
0x0E 0x0F
SystemCommand
Direct parameter page 2 0x10… 0x1F
Vendor specific
NOTE A read operation returns undefined values
3690 3691
B.1.2
3692 3693
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).
3694
Permissible values for these parameters are defined in Table B.2.
MasterCommand
61131-9/WD V0.5 IEC 3695
– 205 –
Working Draft
Table B.2 – Types of MasterCommands Value
MasterCommand
0x00 to 0x59
Reserved
0x5A
Fallback
0x5B to 0x94
Reserved
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.
0x95
MasterIdent
Indicates a Master revision higher than 1.0
0x96
DeviceIdent
Start check of direct parameter page for changed entries
0x97
DeviceStartup
Switches the Device from OPERATE or PREOPERATE to STARTUP
0x98
ProcessDataOutputOperate
Process output data valid
0x99
DeviceOperate
Process output data invalid or not available. Switches the Device from STARTUP or PREOPERATE to OPERATE
0x9A
DevicePreoperate
Switches the Device from STARTUP to state PREOPERATE
0x9B to 0xFF
Reserved
3696 3697
B.1.3
3698 3699 3700
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.
3701
B.1.4
3702 3703
See A.3.7 for the application of the MinCycleTime. The structure of the MinCycleTime parameter is illustrated in Figure B.2.
MasterCycleTime
MinCycleTime
Time base
Multiplier
3704 3705
Figure B.2 – MinCycleTime
3706
Bits 0 to 5: Multiplier
3707 3708
These bits contain a 6-bit multiplier for the calculation of the MinCycleTime. Permissible values for the multiplier are 0 to 63.
3709
Bits 6 to 7: Time Base
3710
These bits contain the time base for the calculation of the MinCycleTime.
3711 3712 3713
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).
3714 3715
The permissible combinations for time base and multiplier are listed in Table B.3 along with the resulting values for MinCycleTime.
Working Draft
61131-9/WD V0.5 IEC
– 206 –
3716
Table B.3 – Possible values of MinCycleTime Code (binary)
Time Base
Calculation
Cycle Time
00
0,1 ms
Multiplier * Time Base
0,4 ms to 6,3 ms
01
0,4 ms
6,4 ms + Multiplier * Time Base
6,4 ms to 31,6 ms
10
1,6 ms
32,0 ms + Multiplier * Time Base
32,0 ms to 132,8 ms
11
Reserved
Reserved
Reserved
3717 3718
B.1.5
3719
The structure of the F-sequence Capability parameter is illustrated in Figure B.3.
F-sequence Capability
PREOPERATE F-sequence type
Reserved
OPERATE F-sequence type
ISDU
3720 3721
Figure B.3 – F-sequence Capability
3722
Bit 0: ISDU
3723 3724
This bit indicates whether or not the ISDU communication channel is supported. Permissible values for ISDU are listed in Table B.4.
3725
Table B.4 – Values of ISDU Value
Definition
0
ISDU not supported
1
ISDU supported
3726 3727
Bits 1 to 3: OPERATE F-sequence type
3728 3729 3730
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.
3731
Bits 4 to 5: PREOPERATE F-sequence type
3732 3733
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.
3734
Bits 6 to 7: Reserved
3735
These bits are reserved and shall be set to zero in this version of the specification.
3736
B.1.6
3737 3738 3739
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.
3740
The legacy protocol version 1.0 is defined in [13]. This specification defines version 1.1.
RevisionID (RID)
61131-9/WD V0.5 IEC
– 207 –
Working Draft
MajorRev
MinorRev
3741 3742
Figure B.4 – RevisionID
3743
Bits 0 to 3: MinorRev
3744 3745
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.
3746
Bits 4 to 7: MajorRev
3747 3748
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.
3749
B.1.7
3750
The structure of the ProcessDataIn parameter is illustrated in Figure B.5.
ProcessDataIn
BYTE
SIO
Reserve
Length
3751 3752
Figure B.5 – ProcessDataIn
3753
Bits 0 to 4: Length
3754 3755 3756
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.
3757
Bit 5: Reserve
3758
This bit is reserved and shall be set to zero in this version of the specification.
3759
Bit 6: SIO
3760 3761
This bit indicates whether the Device provides a switching signal in SIO mode. Permissible values for SIO are listed in Table B.5.
3762
Table B.5 – Values of SIO Value
Definition
0
SIO mode not supported
1
SIO mode supported
3763 3764
Bit 7: BYTE
3765 3766
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.
3767
Table B.6 – Permitted combinations of BYTE and Length BYTE
Length
Definition
0
0
no process data
0
1
1 bit process data, structured in bits
0
...
dito
0
16
16 bit process data, structured in bits
Working Draft
61131-9/WD V0.5 IEC
– 208 – BYTE
Length
Definition
0
17 to 31
Reserved
1
0, 1
Reserved
1
2
3 octets process data, structured in octets
1
...
dito
1
31
32 octets process data, structured in octets
3768 3769
B.1.8
3770 3771
The structure of the ProcessDataOut parameter is the same as with ProcessDataIn, except with bit 6 ("SIO") reserved.
3772
B.1.9
3773 3774
These octets contain a worldwide unique value per vendor. This value is assigned by the organization listed in Annex K.
3775
B.1.10
3776 3777
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.
3778 3779
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.
3780
B.1.11
3781
This parameter will be defined in a later version.
3782
B.1.12
3783 3784 3785
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.
3786 3787
NOTE The SystemCommand on the Direct Parameter page 1 does not provide a positive or negative response upon execution of a selected function
3788
B.1.13
3789 3790
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.
3791 3792
NOTE The complete parameter list of the direct parameter page 2 is read or write accessible via index 1 (see B.1.1).
3793
B.2
3794
B.2.1
3795 3796 3797 3798 3799 3800 3801
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.
ProcessDataOut
VendorID (VID)
DeviceID (DID)
FunctionID (FID)
SystemCommand
Device specific direct parameter page 2
Predefined Device parameters Overview
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
Figure B.6 – Index space for ISDU data objects
3804 3805 3806
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)
All parameters of an Index shall be readable and/or writeable as an entire data object via Subindex 0.
2)
The technology specific device application shall resolve inconsistencies of dependent parameter sets during reparameterization.
3)
The duration of an SPDU service request is limited (Table 91). A master application can abort SPDU services after this timeout.
4)
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
Figure B.7 – Implementation rules for parameters and commands
3809 3810
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.
3811
Table B.7 – Index assignment of data objects (Device parameter) Index (dec)
Object name
0x0000 (0)
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
61131-9/WD V0.5 IEC
– 210 –
Index (dec)
Object name
Access
Length
Data type
M/O/ C
Remark
0x0001 (1)
Direct Parameter Page 2
R/W
0x0002 (2)
SystemCommand
W
0x0003 (3)
Data Storage Index
R/W
0x00040x000B (4-11)
Reserved
0x000C (12)
Device Access Locks
R/W
2 octets
RecordT
C
Standardized Device locking functions (See B.2.4)
0x000D (13)
Profile Characteristic
R
variable
RecordT
O
See [12]
0x000E (14)
PDInput Descriptor
R
variable
RecordT
O
See [12]
0x000F (15)
PDOutput Descriptor
R
variable
RecordT
O
See [12]
0x0010 (16)
Vendor Name
R
max. 64 octets
StringT
M
Informative (See B.2.6)
0x0011 (17)
Vendor Text
R
max. 64 octets
StringT
O
Additional vendor information (See B.2.7)
0x0012 (18)
Product Name
R
max. 64 octets
StringT
M
Detailed product or type name (See B.2.8)
0x0013 (19)
Product ID
R
max. 64 octets
StringT
O
Product or type identification (See B.2.9 and [3] for details)
0x0014 (20)
Product Text
R
max. 64 octets
StringT
O
Description of Device function or characteristic (See B.2.10)
0x0015 (21)
SerialNumber
R
max. 16 octets
StringT
O
Vendor specific serial number (See B.2.11)
0x0016 (22)
Hardware Revision
R
max. 64 octets
StringT
O
Vendor specific format (See B.2.12)
0x0017 (23)
Firmware Revision
R
max. 64 octets
StringT
O
Vendor specific format (See B.2.13)
0x0018 (24)
Application Specific Tag
R/W
Min. 16, max. 32 octets
StringT
O
Tag location or tag function defined by user (See B.2.14)
0x00190x001F (25-31)
Reserved
0x0020 (32)
Error Count
R
2 octets
UIntegerT
O
Errors since power-on or reset (See B.2.15)
0x00210x0023 (33-35)
Reserved
0x0024 (36)
Device Status
R
1 octet
UIntegerT
O
Contains current status of the Device (See B.2.16)
0x0025 (37)
Detailed Device Status
R
variable
RecordT
O
See B.2.17 and [12]
0x00260x0027 (38-39)
Reserved
RecordT
M
Redirected to the page communication channel, see 10.7.4
1 octet
UIntegerT
M/O
Command Code Definition (See B.2.2)
variable
RecordT
M
Set of data objects for storage (See B.2.3) Reserved for exceptional operations
61131-9/WD V0.5 IEC Index (dec)
Object name
– 211 –
Access
Length
Data type
Working Draft M/O/ C
Remark
0x0028 (40)
ProcessDataInput
R
PD length
Device specific
O
Read last valid process data from PDin channel (See B.2.17)
0x0029 (41)
ProcessR DataOutput
PD length
Device specific
O
Read last valid process data from PDout channel (See B.2.19)
0x0020x002F (42-47)
Reserved
0x0030 (48)
Offset Time
O
Synchronization of Device application timing to F-sequence timing (See B.2.20)
0x00310x003F (49-63)
Reserved for profiles
0x00400x00FE (64-254)
Preferred Index
0x00FF (255)
Reserved
0x01000x3FFF (25616383)
Extended Index
Device specific (16 bit)
0x40000x4FFF (1638420479)
Profile specific Index
To be defined within a separate document [12]
0x50000xFFFF (2048065535)
Reserved
Key
R/W
1 octet
RecordT
Device specific (8 bit)
M = mandatory; O = optional; C = conditional
3812 3813
B.2.2
3814 3815 3816 3817 3818
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).
3819 3820
Implementation of the SystemCommand feature is mandatory for Masters and optional for Devices. The coding of SystemCommand is shown in Table B.8.
3821
Table B.8 – Coding of SystemCommand (ISDU)
SystemCommand
Command (hex)
Command (dec)
Command name
M/O
Definition
0x00
0
Reserved
0x01
1
ParamUploadStart
O
Start parameter upload
0x02
2
ParamUploadEnd
O
Stop parameter upload
0x03
3
ParamDownloadStart
O
Start parameter download
0x04
4
ParamDownloadEnd
O
Stop parameter download
0x05
5
ParamDownloadStore
O
Finalize parameterization and start data storage
0x06
6
ParamBreak
O
Cancel all Param commands
0x07 to 0x3F
7 to 63
Reserved
Working Draft Command (hex)
Command (dec)
Command name
M/O
0x40 to 0x7F
64 to 127
Reserved for profiles
0x80
128
Device reset
O
0x81
129
Application reset
O
0x82
130
Restore factory settings
O
0x83 to 0x9F
131 to 159
Reserved
0xA0 to 0xFF
160 to 255
Vendor specific
NOTE
61131-9/WD V0.5 IEC
– 212 –
Definition
See 10.3
Key
M = mandatory; O = optional
3822 3823
The implementation of the parameterization commands is optional. However, all of these commands 0x01 … 0x06 or none of them shall be implemented.
3824
See B.1.12 for SystemCommand options on the direct parameter page 1.
3825
B.2.3
3826 3827
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.
3828
Table B.9 – Data Storage Index assignments Index 0x0003
Data Storage Index
Subindex
Access
Parameter Name
Coding
01
R/W
DS_Command
0x00: 0x01: 0x02: 0x03: 0x04: 0x05: 0x06 to 0xFF:
Reserved DS_UploadStart DS_UploadEnd DS_DownloadStart DS_DownloadEnd DS_Break Reserved
02
R
State_Property
Bit 0: Reserved Bit 1and 2: State of Data Storage 0b00: Inactive 0b01: Upload 0b10: Download 0b11: Data storage locked
Data type UIntegerT (8 bit)
UIntegerT (8 bit)
Bit 3 to 6: Reserved Bit 7: DS_UPLOAD_FLAG "1": DS_UPLOAD_REQ pending "0": no DS_UPLOAD_REQ 03
R
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.
UIntegerT (32 bit)
04
R
Parameter_ Checksum
Parameter set revision indication: CRC signature or Revision Counter (10.4.8)
UIntegerT (32 bit)
05
R
Index_List
List of parameter indices to be saved (Table B.10)
OctetStringT (variable)
3829 3830
DS_Command
3831
This octet carries the Data Storage commands for the Device.
61131-9/WD V0.5 IEC
– 213 –
Working Draft
3832
State_Property
3833 3834 3835
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.
3836
Data_Storage_Size
3837 3838 3839 3840
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.
3841
Parameter_Checksum
3842 3843 3844 3845 3846
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.
3847
Index_List
3848 3849
Table B.10 shows the structure of the Index_List. Each Index_List can carry up to 70 entries (Table 91).
3850
Table B.10 – Structure of Index_List Entry X1
Address
Definition
Data type
Index
Index of first parameter to be saved
Unsigned16
Subindex
Subindex of first parameter to be saved
Unsigned8
Index
Index of next parameter to be saved
Unsigned16
Subindex
Subindex of next parameter to be saved
Unsigned8
…..
………
……………………………………….
………..
Xn
Index
Index of last parameter to be saved
Unsigned16
Subindex
Subindex of last parameter to be saved
Unsigned8
Xn+1
Index
Termination_Marker 0x0000: End of Index_List >0x0000: Next Index containing an Index_List
Unsigned16
X2
3851 3852 3853 3854 3855
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.
3856
B.2.4
3857 3858 3859 3860 3861 3862
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.
3863
The following Device access lock categories are defined.
3864
Parameter write access (optional)
3865
Data storage (mandatory if the Device supports data storage)
Device Access Locks
Working Draft
61131-9/WD V0.5 IEC
– 214 –
3866
Local parameterization (optional)
3867
Local user interface operation (optional)
3868
The following Table B.11 shows the Device locking possibilities.
3869
Table B.11 – Device locking possibilities Bit
Category
Definition
0
Parameter (write) access (optional)
0: unlocked (default) 1: locked
1
Data storage (mandatory if the Device supports data storage)
0: unlocked (default) 1: locked (see NOTE)
2
Local parameterization (optional)
0: unlocked (default) 1: locked
3
Local user interface (optional)
0: unlocked (default) 1: locked
4 - 15
Reserved
NOTE The Master reads the parameter State_Property/State of Data Storage (Table B.9 prior to any actions
3870 3871
Parameter (write) access:
3872 3873 3874 3875
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.
3876 3877
The Data Storage mechanism overrules the parameter (write) access lock mechanism temporarily between DS_DownloadStart and DS_DownloadEnd or DS_Break.
3878
Data storage:
3879 3880 3881
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.
3882
This setting is also indicated in the State Property within Data Storage Index
3883
Local parameterization:
3884
If this bit is set, the parameterization via local control elements on the Device is inhibited.
3885
Local user interface:
3886
If this bit is set, operation of the human machine interface on the Device is disabled.
3887
B.2.5
3888 3889
The profile parameter Profile Characteristic is defined in a separate document [12]. Indices 0x000E to 0x000F are reserved for further Device profiles.
3890
B.2.6
3891 3892 3893
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.
3894
NOTE
Profile Characteristic
Vendor Name
These predefined parameters are always coded as UTF-8 (see E.2.6)
61131-9/WD V0.5 IEC
– 215 –
Working Draft
3895
B.2.7
3896 3897 3898
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.
3899
B.2.8
3900 3901 3902
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.
3903
B.2.9
3904 3905 3906
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.
3907
B.2.10
3908 3909 3910 3911
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.
3912
B.2.11
3913 3914 3915
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.
3916
B.2.12
3917 3918 3919
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.
3920
B.2.13
3921 3922 3923
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.
3924
B.2.14
3925 3926 3927 3928 3929
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.
3930
NOTE
3931
B.2.15
3932 3933 3934 3935
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.
Vendor Text
Product Name
Product ID
Product Text
SerialNumber
Hardware Revision
Firmware Revision
Application Specific Tag
In process automation usually this length is 32 octets.
Error Count
Working Draft
61131-9/WD V0.5 IEC
– 216 –
3936
B.2.16
3937
B.2.16.1
3938 3939 3940
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.
3941 3942 3943
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).
3944 3945 3946
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.
3947
Investigations are in progress to find relevant standards in ISO/IEC if any
Device Status Overview
3948
Table B.12 – Device status parameter Value
Definition
Color indication (process monitoring)
0
Device is OK
Green
1
Maintenance-Required B.2.16.2
Blue
2
Out-of-Specification B.2.16.3
Yellow
3
Functional-Check B.2.16.4
Orange
4
Failure B.2.16.5
Red
5 - 255
Reserved
-
Symbol (process monitoring) None
?
-
3949 3950
B.2.16.2
3951 3952 3953
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.
3954
B.2.16.3
3955 3956 3957 3958
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.).
3959
B.2.16.4
3960 3961
Process Data temporarily invalid due to intended manipulations on the Device (calibrations, teach-in, position adjustments, simulation, etc.).
Maintenance-required
Out-of-Specification
Functional-Check
61131-9/WD V0.5 IEC
– 217 –
Working Draft
3962
B.2.16.5
3963 3964
Process Data invalid due to malfunction in the Device or its peripherals. The Device is unable to perform its intended function.
3965
B.2.17
3966 3967 3968 3969 3970 3971 3972 3973 3974 3975
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.
3976
Table B.13 – Detailed Device Status (Index 0x0025)
Failure
Detailed Device Status
Subindex
Object name
R/W
Mandatory /optional
Data Type
Comment
1
Error_Warning_1
R
M
3 octets
All octets 0x00: no Error/ Warning Octet 1: EventQualifier Octet 2,3: EventCode
2
Error_Warning_2
R
M
3 octets
dito
3
Error_Warning_3
R
M
3 octets
dito
4
Error_Warning_4
R
M
3 octets
dito
Error_Warning_n
R
M
3 octets
dito
… n
3977 3978
Table B.13 shows the structure of the parameter Detailed Device Status [12].
3979 3980
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.
3981
B.2.18
3982 3983 3984 3985
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.
3986
B.2.19
3987 3988 3989 3990
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.
3991
B.2.20
3992 3993 3994 3995
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.
ProcessDataInput
ProcessDataOutput
Offset Time
Working Draft 3996
61131-9/WD V0.5 IEC
– 218 –
The structure of the parameter Offset Time is illustrated in the following Figure B.8: Multiplier
Time base
3997 3998
Figure B.8 – Structure of the Offset Time
3999
Bits 0 to 5: Multiplier
4000 4001
These bits contain a 6-bit factor for the calculation of the Offset Time. Permissible values for the multiplier are 0 to 63.
4002
Bits 6 to 7: Time Base
4003
These bits contain the time base for the calculation of the Offset Time.
4004 4005 4006 4007
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)
4008
Table B.14 – Time base coding and values of Offset Time Code (binary)
Time Base
Calculation
Offset Time
00
0,01 ms
Multiplier * Time Base
0,01 ms to 0,63 ms
01
0,04 ms
0,64 ms + Multiplier * Time Base
0,64 ms to 3,16 ms
10
0,64 ms
3,20 ms + Multiplier * Time Base
3,20 ms to 43,52 ms
11
2,56 ms
44,16 ms + Multiplier * Time Base
44,16 ms to 126,08 ms
4009 4010
B.2.21
4011 4012
Indices 0x0031 to 0x003F are reserved for Device profiles. These parameters will be specified within a separate document [12].
4013
B.2.22
4014 4015 4016 4017
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).
4018
B.2.23
4019
Extended Indices (0x0100 to 0x3FFF) can be used for vendor specific Device functions.
4020
B.2.24
4021 4022
Indices 0x4000 to 0x4FFF are reserved for Device profiles. These parameters will be specified within a separate document [12].
Profile Parameter (reserved)
Preferred Index
Extended Index
Profile specific Index (reserved)
61131-9/WD V0.5 IEC 4023 4024 4025
– 219 –
Working Draft
Annex C (normative) ErrorTypes (ISDU errors)
4026
C.1
4027 4028 4029
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).
4030
The ErrorType consists of two octets, the main error cause and more specific information:
4031
ErrorCode (high order octet)
4032
AdditionalCode (low order octet)
4033 4034 4035
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.
4036
C.2
4037
C.2.1
4038
The permissible ErrorTypes resulting from the Device application are listed in Table C.1.
General
Application related ErrorTypes Overview
4039
Table C.1 – ErrorTypes Incident
Error Code
Additional Code
Name
Definition
Device application error – no details
0x80
0x00
APP_DEV
See C.2.2
Index not available
0x80
0x11
IDX_NOTAVAIL
See C.2.3
Subindex not available
0x80
0x12
SUBIDX_NOTAVAIL
See C.2.4
Service temporarily not available
0x80
0x20
SERV_NOTAVAIL
See C.2.5
Service temporarily not available - local control
0x80
0x21
SERV_NOTAVAIL_LOCCTRL
See C.2.6
Service temporarily not available – Device control
0x80
0x22
SERV_NOTAVAIL_DEVCTRL
See C.2.7
Access denied
0x80
0x23
IDX_NOT_WRITABLE
See C.2.8
Parameter value out of range
0x80
0x30
PAR_VALOUTOFRNG
See C.2.9
Parameter value above limit
0x80
0x31
PAR_VALGTLIM
See C.2.10
Parameter value below limit
0x80
0x32
PAR_VALLTLIM
See C.2.11
Parameter length overrun
0x80
0x33
VAL_LENOVRRUN
See C.2.12
Parameter length underrun
0x80
0x34
VAL_LENUNDRUN
See C.2.13
Working Draft Incident
61131-9/WD V0.5 IEC
– 220 – Error Code
Additional Code
Name
Definition
Function not available
0x80
0x35
FUNC_NOTAVAIL
See C.2.14
Function temporarily unavailable
0x80
0x36
FUNC_UNAVAILTEMP
See C.2.15
Invalid parameter set
0x80
0x40
PAR_SETINVALID
See C.2.16
Inconsistent parameter set
0x80
0x41
PAR_SETINCONSIST
See C.2.17
Application not ready
0x80
0x82
APP_DEVNOTRDY
See C.2.18
Vendor specific
0x81
0x00
UNSPECIFIC
See C.2.19
Vendor specific
0x81
0x01 to 0xFF
VENDOR_SPECIFIC
See C.2.19
4040 4041
C.2.2
4042 4043
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.
4044
C.2.3
4045
This ErrorType shall be used whenever a read or write access occurs to a not existing Index.
4046
C.2.4
4047 4048
This ErrorType shall be used whenever a read or write access occurs to a not existing Subindex.
4049
C.2.5
4050 4051
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.
4052
C.2.6
4053 4054 4055
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).
4056
C.2.7
4057 4058 4059
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).
4060
C.2.8
4061
This ErrorType shall be used if a write service tries to access a read-only parameter.
4062
C.2.9
4063 4064
This ErrorType shall be used for a write service to a parameter outside its permitted range of values.
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
61131-9/WD V0.5 IEC
– 221 –
Working Draft
4065
C.2.10
4066 4067
This ErrorType shall be used for a write service to a parameter above its specified value range.
4068
C.2.11
4069 4070
This ErrorType shall be used for a write service to a parameter below its specified value range.
4071
C.2.12
4072 4073 4074
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).
4075
C.2.13
4076 4077
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).
4078
C.2.14
4079 4080
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).
4081
C.2.15
4082 4083 4084
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).
4085
C.2.16
4086 4087
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).
4088
C.2.17
4089 4090 4091
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).
4092
C.2.18
4093 4094
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).
4095
C.2.19
4096 4097
This ErrorType will be propagated directly to higher level processing elements as an error (no warning) by the Master.
4098
Parameter value above limit
Parameter value below limit
Parameter length overrun
Parameter length underrun
Function not available
Function temporarily unavailable
Invalid parameter set
Inconsistent parameter set
Application not ready
Vendor specific
Working Draft
61131-9/WD V0.5 IEC
– 222 –
4099
C.3
4100
C.3.1
4101 4102
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.
4103
Table C.2 – Derived ErrorTypes
Derived ErrorTypes Overview
Incident
Error Code
Additional Code
Name
Definition
Communication error
0x10
0x00
COM_ERR
See C.3.2
Timeout
0x11
0x00
SERV_TIMEOUT
See C.3.3
Device event – ISDU error (DL, Error, single shot, 0x5600)
0x11
0x00
SERV_TIMEOUT
See C.3.4
Device event – ISDU illegal service primitive (AL, Error, single shot, 0x5800)
0x11
0x00
SERV_TIMEOUT
See C.3.5
Master – ISDU checksum error
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
C.3.2
4106 4107
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.
4108
C.3.3
4109 4110
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.
4111
C.3.4
4112 4113 4114
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).
4115
C.3.5
4116 4117 4118
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).
4119
C.3.6
4120 4121
The Master generates a negative service response with this ErrorType, if its data link layer detects an ISDU checksum error.
Communication error
Timeout
Device event – ISDU error
Device event – ISDU illegal service primitive
Master – ISDU checksum error
61131-9/WD V0.5 IEC
– 223 –
Working Draft
4122
C.3.7
4123 4124
The Master generates a negative service response with this ErrorType, if its data link layer detects an ISDU illegal service primitive.
4125
C.3.8
4126 4127 4128
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).
Master – ISDU illegal service primitive
Device event – ISDU buffer overflow
Working Draft 4129 4130 4131
61131-9/WD V0.5 IEC
– 224 –
Annex D (normative) EventCodes (diagnosis information)
4132
D.1
4133 4134 4135 4136 4137 4138
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.
4139
D.2
4140 4141
Table D.1 lists the defined EventCode identifiers and their definitions. The EventCodes are created by the technology specific Device application (instance = APP).
4142
Table D.1 – EventCodes
General
EventCodes for Devices
EventCodes
Definition
Device Status Value (NOTE 1)
TYPE (NOTE 2)
0x0000
No malfunction
0
Notification
0x1000
General malfunction – unknown error
4
Error
0x1001 to 0x17FF
Reserved
0x1800 to 0x18FF
Manufacturer/ vendor specific
0x1900 to 0x3FFF
Reserved
0x4000
Temperature fault – Overload
4
Error
0x4001 to 0x420F
Reserved
0x4210
Device temperature over-run – Clear source of heat
2
Warning
0x4211 to 0x421F
Reserved
0x4220
Device temperature under-run – Insulate Device
2
Warning
0x4221 to 0x4FFF
Reserved
0x5000
Device hardware fault – Device exchange
4
Error
0x5001 to 0x500F
Reserved
0x5010
Component malfunction – Repair or exchange
4
Error
0x5011
Non volatile memory loss – Check batteries
4
Error
0x5012
Batteries low – Exchange batteries
2
Warning
0x5013 to 0x50FF
Reserved
0x5100
General power supply fault – Check availability
4
Error
0x5101
Fuse blown/open – Exchange fuse
4
Error
0x5102 to 0x510F
Reserved
0x5110
Primary supply voltage over-run – Check tolerance
2
Warning
0x5111
Primary supply voltage under-run – Check tolerance
2
Warning
0x5112
Secondary supply voltage fault (Port Class B) – Check tolerance
2
Warning
0x5113 to 0x5FFF
Reserved
0x6000
Device software fault – Check firmware revision
4
Error
61131-9/WD V0.5 IEC
– 225 –
Working Draft
0x6001 to 0x631F
Reserved
0x6320
Parameter error – Check data sheet and values
4
Error
0x6321
Parameter missing – Check data sheet
4
Error
0x6322 to 0x634F
Reserved
0x6350
Parameter changed – Check configuration
4
Error
0x6351 to 0x76FF
Reserved
0x7700
Wire break of a subordinate device – Check installation
4
Error
0x7701 to 0x770F
Wire break of subordinate device 1 …device 15 – Check installation
4
Error
0x7710
Short circuit – Check installation
4
Error
0x7711
Ground fault – Check installation
4
Error
0x7712 to 0x8BFF
Reserved
0x8C00
Technology specific application fault – Reset Device
4
Error
0x8C01
Simulation active – Check operational mode
3
Warning
0x8C02 to 0x8C0F
Reserved
0x8C10
Process variable range over-run – Process Data uncertain
2
Warning
0x8C11 to 0x8C1F
Reserved
0x8C20
Measurement range over-run – Check application
4
Error
0x8C21 to 0x8C2F
Reserved
0x8C30
Process variable range under-run – Process Data uncertain
2
Warning
0x8C31 to 0x8C3F
Reserved
0x8C40
Maintenance required – Cleaning
1
Notification
0x8C41
Maintenance required – Refill
1
Notification
0x8C42
Maintenance required – Exchange wear and tear parts
1
Notification
0x8C43 to 0x8C9F
Reserved
0x8CA0 to 0x8DFF
Manufacturer/ vendor specific
0x8E00 to 0xAFFF
Reserved
0xB000 to 0xBFFF
Reserved for profiles [12]
0xC000 to 0xFEFF
Reserved
0xFF00 to 0xFFFF
SDCI specific EventCodes (see Table D.2)
NOTE 1 NOTE 2
See B.2.16 See Table A.19
4143 4144 4145 4146
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.
4147
Table D.2 – Exemplary SDCI specific EventCodes Incident
Origin
Instance
Type
Mode
Name
Event Code
Action
Remark
With details Process Data Address increment error
Remote
DL
ERROR
Singleshot
PD_INCR
0xFFE1
PD stop
Missing PD address
Working Draft Incident
61131-9/WD V0.5 IEC
– 226 – Origin
Instance
Type
Mode
Name
Event Code
Action
Remark
Access outside PD length
Remote
DL
ERROR
Singleshot
PD_LEN
0xFFE2
PD stop
Written or read PD length too long
Incomplete PD length
Remote
DL
ERROR
Singleshot
PD_SHORT
0xFFE3
PD stop
Written or read PD length too short
Read at input length "0"
Remote
DL
ERROR
Singleshot
NO_PDIN
0xFFE4
PD stop
Write at output Remote length "0"
DL
ERROR
Singleshot
NO_PDOUT
0xFFE5
PD stop
System Management Mode indication
Local
DL
NOTIFICATION
Singleshot
NEW_SLAVE
0xFF21
PD stop
See 11
Device communication lost
Local
APP
NOTIFICATION
Singleshot
DEV_COM_ LOST
0xFF22
-
See 11
Data Storage identification mismatch
Local
APP
NOTIFICATION
Singleshot
DS_IDENT_ MISMATCH
0xFF23
-
See 11
Data Storage Local buffer overflow
APP
NOTIFICATION
Singleshot
DS_BUFFER _OVERFLOW
0xFF24
-
See 11
Local
APP
NOTIFICATION
Singleshot
DS_ACCESS _DENIED
0xFF25
-
See 11
Local
DL
ERROR
Singleshot
EVENT
0xFF31
Event.ind
See 11
DS_UPLOAD _REQ
0xFF91
Event.ind
0xFF98
Event.ind
Data Storage parameter access denied Unspecified Incorrect event signalling
Device specific application
4148
Data Storage upload request
Remote
APP
NOTIFICATION
Singleshot
Reserved
Remote
APP
NOTIFICATION
Singleshot
Shall not be used
61131-9/WD V0.5 IEC
– 227 –
4149 4150 4151
Working Draft
Annex E (normative) Data types
4152
E.1
4153 4154 4155
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.
4156
E.2
4157
E.2.1
4158
The coding of basic data types is shown only for singular use, which is characterized by
4159
Process data consisting of one basic data type
4160
Parameter consisting of one basic data type
4161 4162
Subindex (>0) access on individual data items of parameters of composite data types (arrays, records)
4163
E.2.2
4164 4165 4166 4167 4168
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.
4169
Table E.1 – BooleanT
General
Basic data types General
BooleanT
Data type name BooleanT
Value range
Resolution
TRUE / FALSE
-
Length 1 bit or 1 octet
4170 4171
Table E.2 – BooleanT coding Bit
7
6
5
4
3
2
1
0
Values
TRUE
1
1
1
1
1
1
1
1
0xFF
FALSE
0
0
0
0
0
0
0
0
0x00
4172 4173
E.2.3
4174 4175 4176 4177
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.
UIntegerT
Working Draft Value = 13
61131-9/WD V0.5 IEC
– 228 – 11
11
00
11
11
11
00
11
4 bit 1 octet 00
00
00
00
Padding bits = 0
Value = 93786
11
00
11
11 00
11
11
11
00
00
11
00
11
11
00
11
00
11
00
11
11 00
11
11
11
00
00
11
00
11
11
00
11
00
17 bit 4 octets 00
00
00
00
00
00
00
00
00
00
00
00
00
00
Padding bits = 0
4178 4179 4180
00
Figure E.1 – Coding examples of UIntegerT The data type UIntegerT is defined in Table E.3 for singular use.
4181 4182
Table E.3 – UIntegerT Data type name UIntegerT
Value range
Resolution
0 … 2 bitlength - 1
NOTE 1
High order padding bits are filled with "0"
NOTE 2
Most significant octet (MSO) sent first
1
Length 1 2 4 8
octet, or octets, or octets, or octets
4183 4184
E.2.4
4185 4186 4187 4188 4189
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).
4190
Table E.4 – IntegerT
IntegerT
Data type name IntegerT
Value range -2 bitlength -1 … 2 bitlength -1 - 1
Resolution 1
Length 1 2 4 8
octet, or octets, or octets, or octets
NOTE 1
High order padding bits are filled with the value of the sign bit (SN)
NOTE 2
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
– 229 –
Working Draft
Table E.5 – IntegerT coding (8 octets) Bit
7
6
5
4
3
2
1
0
Octet 1
SN
2 62
2 61
2 60
2 59
2 58
2 57
2 56
Octet 2
2 55
2 54
2 53
2 52
2 51
2 50
2 49
2 48
Octet 3
2 47
2 46
2 45
2 44
2 43
2 42
2 41
2 40
Octet 4
2 39
2 38
2 37
2 36
2 35
2 34
2 33
2 32
Octet 5
2 31
2 30
2 29
2 28
2 27
2 26
2 25
2 24
Octet 6
2 23
2 22
2 21
2 20
2 19
2 18
2 17
2 16
Octet 7
2 15
2 14
2 13
2 12
2 11
2 10
29
28
Octet 8
27
26
25
24
23
22
21
20
Container 8 octets
4195 4196
Table E.6 – IntegerT coding (4 octets) Bit
7
6
5
4
3
2
1
0
Octet 1
SN
2 30
2 29
2 28
2 27
2 26
2 25
2 24
Octet 2
2 23
2 22
2 21
2 20
2 19
2 18
2 17
2 16
Octet 3
2 15
2 14
2 13
2 12
2 11
2 10
29
28
Octet 4
27
26
25
24
23
22
21
20
Container 4 octets
4197 4198
Table E.7 – IntegerT coding (2 octets) Bit
7
6
5
4
3
2
1
0
Octet 1
SN
2 14
2 13
2 12
2 11
2 10
29
28
Octet 2
27
26
25
24
23
22
21
20
Container 2 octets
4199 4200
Table E.8 – IntegerT coding (1 octet) Bit Octet 1
7
6
5
4
3
2
1
0
SN
26
25
24
23
22
21
20
4201 4202
Coding examples within containers are shown in Figure E.2
Container 1 octet
Working Draft
61131-9/WD V0.5 IEC
– 230 –
SN
SN Value = -4
11
11
11
11
11
11
00
00
11
11
00
00
SN = 0: positive numbers and zero SN = 1: negative numbers (Two's complement)
Value = +4
00
Padding bits = 1 (SN)
00
00
00
00
11
00
00
00
11
00
00
Padding bits = 0 (SN) SN
Value = -28250
17 bit 4 octets
11
11
00
00
11
00
00
00
11
11
00
11
00
00
11
11
00
11
11
00
00
11
00
00
00
11
11
00
11
00
00
11
11
00
SN 11
11
11
11
11
11
11
11
11
11
11
11
11
11
11
Padding bits = 1 (SN)
4203 4204
Figure E.2 – Coding examples of IntegerT
4205 4206
E.2.5
4207 4208 4209
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.
4210
Table E.9 – Float32T
Float32T
Data type name Float32T
Value range
Resolution
Refer to [10]
Length
Refer to [10]
4 octets
4211 4212
Table E.10 – Coding of Float32T Bits Octet 1
7
5
4
SN 20
Octet 2
6
3
1
0
Exponent (E) 27
26
25
(E) 20
2
24
23
22
21
2 -5
2 -6
2 -7
2 -13
2 -14
2 -15
2 -21
2 -22
2 -23
Fraction (F) 2 -1
2 -2
Octet 3
2 -3
2 -4
Fraction (F) 2 -8
2 -9
2 -10
Octet 4
2 -11
2 -12
Fraction (F) 2 -16
2 -17
2 -18
2 -19
2 -20
4213 4214 4215
In order to realize negative exponent values a special exponent encoding mechanism is set in place as follows:
4216 4217
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
– 231 –
Working Draft
4218
E min = 0x01 - 0x7F = -126
4219
E max = 0xFE - 0x7F = 127
4220
Exponent bias = 0x7F = 127
4221 4222
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.
4223 4224
E.2.6
4225 4226 4227 4228
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.
4229
Table E.11 – StringT
StringT
Data type name StringT
Encoding
Standards
US-ASCII
[11]
UTF-8
[7]
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
1
2
3
4
5
6
0x48 0x48
0x45 0x45
0x4C 0x4C
0x4C 0x4C
0x4F 0x4F
0x00 0x00
0x00 0x00
H
4237
E
L
L
Sender: 'fixedLength' =7 Padding of unused octets = 0x00
O
0x48 0x48
0x45 0x45
0x4C 0x4C
0x4C 0x4C
0x4F 0x4F
0x48 0x48
0x45 0x45
0x4C 0x4C
0x4C 0x4C
0x4F 0x4F
4238
Octet number
Transmission options: StringT can be transmitted in condensed form or unmodified.
0x00 0x00
0x00 0x00
Receiver: 'fixedLength' =7 Padding of unused octets = 0x00
Figure E.3 – Singular access of StringT
4239 4240
E.2.7
4241 4242 4243
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.
OctetStringT
Working Draft
61131-9/WD V0.5 IEC
– 232 –
4244
Table E.12 – OctetStringT Data type name
Value range
OctetStringT NOTE
Standards
0x00 … 0xFF per octet
Length
-
Fixed length with a maximum of 232 octets
The length is defined within a Device's IODD via the attribute 'fixedLength'.
4245
4246
0
1
0x1F 0x1F
0x0A 0x0A
4247
2 0x23 0x23
3 0xAA 0xAA
4 0xBB 0xBB
5
6
0xA1 0xA1
0xD0 0xD0
Octet number
Figure E.4 – Coding example of OctetStringT
4248 4249
E.2.8
4250 4251 4252 4253
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.
4254 4255 4256 4257 4258 4259
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.
TimeT
New definition in IEC 61158-6:2003 RFC 1305 Standard 1900-01-01 0x00000000 s
4260 4261
1984-01-01
2036-02-07
0x9DFF4400 s
0xFFFFFFFF s
Time
Figure E.5 – New definition of NetworkTime in IEC 61158-6:2003
4262 4263
Table E.13 – TimeT Data type name TimeT
NOTE
Value range
Resolution
Octet 1 to 4 (see Table E.14): 0 i (2 32 -1)
s (Seconds)
Octet 5 to 8 (see Table E.14): 0 i (2 32 -1)
(1/2 32 ) s
32 bit unsigned integer are normal computer science data types
Length 8 Octets (32 bit unsigned integer + 32 bit unsigned integer)
61131-9/WD V0.5 IEC
– 233 –
Working Draft
4264 4265
Table E.14 – Coding of TimeT Bit
7
6
5
4
3
2
1
0
Octet 1
2 31
2 30
2 29
2 28
2 27
2 26
2 25
2 24
Octet 2
2 23
2 22
2 21
2 20
2 19
2 18
2 17
2 16
Octet 3
2 15
2 14
2 13
2 12
2 11
2 10
29
28
Octet 4
27
26
25
24
23
22
21
20
Octet 5
2 31
2 30
2 29
2 28
2 27
2 26
2 25
2 24
Octet 6
2 23
2 22
2 21
2 20
2 19
2 18
2 17
2 16
Octet 7
2 15
2 14
2 13
2 12
2 11
2 10
29
28
Octet 8
27
26
25
24
23
22
21
20
MSB
LSB
Definitions Seconds since 1900-01-01 0.00,00 or since 2036-02-07 6.28,16 when time value less than 0x9DFF4400.00000000
Fractional part of seconds. One unit is 1/(2 32 ) s
MSB = Most significant bit LSB = Least significant bit
4266 4267
E.2.9
4268 4269 4270 4271
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.
4272
Table E.15 – TimeSpanT
TimeSpanT
Data type name
Value range
TimeSpanT
NOTE
Resolution
Octet 1 to 4 (see Table E.16): -2 31 i (2 31 -1)
s (Seconds)
Octet 5 to 8 (see Table E.16): 0 i (2 32 -1)
(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
Table E.16 – Coding of TimeSpanT Bit
7
6
5
4
3
2
1
0
Octet 1
2 31
2 30
2 29
2 28
2 27
2 26
2 25
2 24
Octet 2
2 23
2 22
2 21
2 20
2 19
2 18
2 17
2 16
Octet 3
2 15
2 14
2 13
2 12
2 11
2 10
29
28
Octet 4
27
26
25
24
23
22
21
20
Octet 5
2 31
2 30
2 29
2 28
2 27
2 26
2 25
2 24
Octet 6
2 23
2 22
2 21
2 20
2 19
2 18
2 17
2 16
Octet 7
2 15
2 14
2 13
2 12
2 11
2 10
29
28
Octet 8
27
26
25
24
23
22
21
20
Definitions Seconds (s) as 32 bit integer
Fractional part of seconds as 32 bit unsigned integer. One unit is 1/(2 32 ) s.
Working Draft
61131-9/WD V0.5 IEC
– 234 – MSB
LSB
MSB = Most significant bit LSB = Least significant bit
4275 4276
E.3
4277
E.3.1
4278 4279 4280 4281
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".
4282
E.3.2
4283 4284 4285
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.
Composite data types
1)
General
ArrayT
The Subindex data items are packed in a row without gaps describing an octet sequence
2)
The highest Subindex data item n starts right-aligned within the octet sequence
3)
UIntegerT and IntegerT with a length of ≥ 58 bit and < 64 bit are not permitted
4286 4287
Figure E.6 – Structuring rules for ArrayT
4288 4289
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.
4290
Table E.17 – Example for the access of an ArrayT Index 66
Subindex
Offset
Data items
1
12
0x2
2
9
0x6
3
6
0x4
4
3
0x7
5
0
0x5
Data Type IntegerT, 'bitLength' = 3
4291 Transmission direction
Bit 15
Bit 0
00 11 00 11 11 00 11
Bit offset:
12 "Subindex1"
4292 4293
9
00 00 11 11 11 11 00 11
6 "Subindex3"
"Subindex2"
3
0
"Subindex5"
"Subindex4"
Figure E.7 – Example of an ArrayT data structure
61131-9/WD V0.5 IEC
– 235 –
Working Draft
4294
E.3.3
4295 4296 4297 4298
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.
RecordT
4)
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.
5)
Bit offsets shall always be indicated within this octet sequence (may show no strict order in the IODD)
6)
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
7)
The following data types shall always be aligned on octet boundaries: Float32T, StringT, OctetStringT, TimeT, and TimeSpanT
8)
UIntegerT and IntegerT with a length of ≥ 58 bit shall always be aligned on one side of an octet boundary
9)
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
Figure E.8 – Structuring rules for RecordT
4301 4302
Table E.18 shows an example 1 for the access of a RecordT. It consists of varied parameters named "Status", "Text", and "Value".
4303
Table E.18 – Example 1 for the access of a RecordT Index 47
NOTE
Subindex
Offset
Data items
1
88
0x23 0x45
2
32
H
3
0
0x56 0x12 0x22 0x34
E
L
L
O
Data Type
0x00
0x00
Name
UIntegerT, 'bitLength' = 16
Status
StringT, 'fixedLength' = 7
Text
UIntegerT, 'bitLength' = 32
Value
'bitLength' and 'fixedLength' are defined in the IODD of the particular Device
4304 4305 4306
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.
4307
Table E.19 – Example 2 for the access of a RecordT Index 46
NOTE
Subindex
Offset
Data items
1
2
0x32
2
1
3
0
0xF1
Data Type
Name
UIntegerT, 'bitLength' = 14
Level
FALSE
BooleanT
Min
TRUE
BooleanT
Max
'bitLength' is defined in the IODD of the particular Device
Working Draft
61131-9/WD V0.5 IEC
– 236 – Transmission direction
Bit 15
Bit 0
11 11 00 00 11 00 11 11
11 11 00 00 00 11 00 11
2 1 0
Bit offset: "Level"
"Min" "Max"
4308 4309
Figure E.9 – Example 2 of a RecordT structure
4310 4311 4312
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.
4313
Table E.20 – Example 3 for the access of a RecordT Index
Subindex
Offset
45
1
32
2 3
NOTE
Data items
Data Type
Name
TRUE
BooleanT
NewBit
33
FALSE
BooleanT
DR4
34
FALSE
BooleanT
CR3
4
35
TRUE
BooleanT
CR2
5
38
TRUE
BooleanT
Control
6
16
0xF8
OctetStringT, 'fixedLength' = 2
Setpoint
7
8
0x41
StringT, 'fixedLength' = 1
Unit
8
0
0xC3
OctetStringT, 'fixedLength' = 1
Enable
0x23
'fixedLength' is defined in the IODD of the particular Device
4314 Transmission direction
Bit 0
Bit 39
0xF8 0xF8
Bit offset:
4315
38
35
0x23 0x23
0x41 0x41
16
32 "Setpoint"
0xC3 0xC3
8 "Unit"
"Enable"
4316
Figure E.10 – Example 3 of a RecordT structure
4317 4318
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
– 237 –
Selective write of a variable within the record
Working Draft Write of a record Write request 0001
1000
Index = 45 Write request 0010
4319 4320 4321
0101
0x49 0xF8
Index = 45
0x23
Subindex = 4
0x41
0x01
0xC3
CHKPDU
CHKPDU
Figure E.11 – Write requests for example 3
Working Draft
61131-9/WD V0.5 IEC
– 238 –
4322 4323 4324
Annex F ( normative) Structure of the Data Storage data object
4325 4326
Table F.1 illustrates the structure of a Data Storage (DS) data object within the Master (See 11.3.2).
4327
Table F.1 – Structure of the stored DS data object Part
Object 1
Object 2
Parameter name
Definition
Data type
ISDU_Index
ISDU Index (0 to 65 535)
Unsigned16
ISDU_Subindex
ISDU Index (0 to 255)
Unsigned8
ISDU_Length
Length of the subsequent record
Unsigned8
ISDU_Data
Record of length ISDU_Length
Record
ISDU_Index
ISDU Index (0 to 65 535)
Unsigned16
ISDU_Subindex
ISDU Index (0 to 255)
Unsigned8
ISDU_Length
Length of the subsequent record
Unsigned8
ISDU_Data
Record of length ISDU_Length
Record
---------ISDU_Index Object n
ISDU Index (0 to 65 535)
Unsigned16
ISDU_Subindex
ISDU Index (0 to 255)
Unsigned8
ISDU_Length
Length of the subsequent record
Unsigned8
ISDU _Data
Record of length ISDU_Length
Record
4328 4329 4330
The Device shall calculate the required memory size by summarizing the objects 1 to n (See Table B.9, Subindex 3).
4331 4332
The Master shall store locally in non-volatile memory the header information shown in Table F.2. See Table B.9.
4333
Table F.2 – Associated header information for stored DS data objects Part Header
4334
Parameter name
Definition
Data type
Parameter Checksum
32 bit CRC signature or revision counter (10.4.8)
Unsigned32
VendorID
See B.1.9
Unsigned16
DeviceID
See B.1.10
Unsigned32
FunctionID
See B.1.11
Unsigned16
61131-9/WD V0.5 IEC 4335 4336 4337
– 239 –
Working Draft
Annex G ( normative) Master and Device conformity
4338
G.1
4339
G.1.1
4340
To be defined in conjunction with [14].
4341
G.1.2
4342
To be defined in conjunction with [14].
4343
G.1.3
4344
To be defined in conjunction with [14].
4345
G.2
4346
G.2.1
4347 4348 4349 4350 4351
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.
4352 4353 4354 4355
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.
4356
G.2.2
4357 4358 4359 4360 4361
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.
4362
G.2.3
4363
a) Performance criterion A
4364 4365 4366
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.
Conformance classes Overview
Functional requirements for Devices
Functional requirements for Master
Electromagnetic compatibility requirements (EMC) General
Operating conditions
Performance criteria
Working Draft
61131-9/WD V0.5 IEC
– 240 –
4367
Table G.1 – EMC test conditions for SDCI Transmission rate
Master t CYC
Device t CYC
Number of F-sequences of TYPE_2_5 (read) (6 octets)
Number of F-sequences of TYPE_0 (read) (4 octets)
Maximum of Fsequence errors
4,8 Kbit/s
18,0 ms
300 (6 000)
100 T BIT (20,84 ms)
350 (7 000)
6
38,4 Kbit/s
2,3 ms
450 (9 000)
100 T BIT (2,61 ms)
500 (10 000)
6
230,4 Kbit/s
0,4 ms
700 (14 000)
100 T BIT (0,44 ms)
800 (16 000)
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
b) Performance Criterion B
4370 4371
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.
4372
G.2.4
4373
Table G.2 specifies the EMC tests to be performed.
Required immunity tests
4374
Table G.2 – EMC test levels Phenomena Electrostatic discharges (ESD) IEC 61000-4-2
Test Level Air discharge: ± 8 kV
Performance Criterion
Constraints
B
See NOTE 1
A
See NOTE 1 and NOTE 2
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
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)
± 1 kV
A
IEC 61000-4-4
± 2 kV
B
Surge
Not required for an SDCI link (SDCI link is limited to 20 m)
-
0,15 MHz – 80 MHz 10 VEMF
See NOTE 2 and NOTE 4
IEC 61000-4-5 Radio-frequency common mode IEC 61000-4-6 Voltage dips and interruptions IEC 61000-4-11
A
Not required for an SDCI link
61131-9/WD V0.5 IEC
– 241 –
Phenomena
Test Level
Working Draft Performance Criterion
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
G.2.5
4377 4378 4379
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.
4380 4381
All emission tests shall be performed at the fastest possible communication rate with the fastest cycle time.
4382
G.2.6
4383
G.2.6.1
4384
The following rules apply for the test of Masters:
4385 4386
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.
4387 4388
Grounding of the Master and the Devices shall be according to the relevant product standard or manual.
4389 4390 4391
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.
4392
Where applicable, the auxiliary Devices shall be placed 10 cm above RefGND.
4393 4394
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.
4395
Each port shall fulfill the EMC requirements.
4396
G.2.6.2
4397
Figure G.1 shows the test setup for electrostatic discharge according IEC 61000-4-2.
Required emission tests
Test configurations for Master General rules
Electrostatic discharges
Power Supply
AUX 1 (Device)
EUT (Master)
AUX 2 (Device)
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
61131-9/WD V0.5 IEC
– 242 –
4400
G.2.6.3
4401 4402
Figure G.2 shows the test setup for radio-frequency electromagnetic field according IEC 61000-4-3.
Radio-frequency electromagnetic field
Power Supply
AUX 1 (Device)
EUT (Master)
AUX 2 (Device)
Uniform area l = 1,0 m
l = 1,0 m
D=0,3 m
Ferrite clamp or other decoupling
4403 4404
Figure G.2 – Test setup for RF electromagnetic field (Master)
4405
G.2.6.4
4406
Figure G.3 shows the test setup for fast transients according IEC 61000-4-4.
Fast transients (burst)
AUX 1 (Device)
CCC
Power Supply
CDN
EUT (Master)
AUX 2 (Device)
D=0,3 m l = 0,5 m
l = 0,5 m
4407 4408
l = 0,5 m
Figure G.3 – Test setup for fast transients (Master)
4409
NOTE 1
No coupling into SDCI line to AUX 2 is required
4410
NOTE 2
CDN: Coupling/Decoupling Network
4411
NOTE 3
CCC: Capacitive coupling clamp
4412
G.2.6.5
4413
Figure G.4 shows the test setup for radio-frequency common mode according IEC 61000-4-6.
Radio-frequency common mode
Power Supply
4415
EUT (Master)
x
x
Figure G.4 – Test setup for RF common mode (Master)
4416
NOTE 1
0,1 m < x < 0,3 m
4417
NOTE 2
SDCI overall cable length = 1 m
4418
CDN
x
4414
AUX 1 (Device)
EM-Clamp
61131-9/WD V0.5 IEC
– 243 –
Working Draft
4419
G.2.7
4420
G.2.7.1
4421
For the test of Devices the following rules apply:
4422 4423
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.
4424 4425
Grounding of the Master and the Devices according to the relevant product standard or user manual.
4426 4427 4428
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.
4429
Where applicable, the auxiliary Devices shall be placed 10 cm above RefGND.
4430
Test with Device AUX 2 is optional
Test configurations for Devices General rules
4431 4432
G.2.7.2
4433
Figure G.5 shows the test setup for electrostatic discharge according to IEC 61000-4-2.
Electrostatic discharges
Power Supply
AUX 1 (Master)
D=0,3 m
AUX 2 (Device)
4434 4435
EUT (Device)
d ≥ 1,0 m
Figure G.5 – Test setup for electrostatic discharges (Device)
4436
G.2.7.3
4437 4438
Figure G.6 shows the test setup for radio-frequency electromagnetic field according to IEC 61000-4-3.
Radio-frequency electromagnetic field
Power Supply
AUX 1 (Master)
AUX 2 (Device)
4439 4440
EUT (Device)
D=0,3 m Ferrite clamp or other decoupling
l = 1,0 m
Uniform area
Figure G.6 – Test setup for RF electromagnetic field (Device)
4441
G.2.7.4
4442
Figure G.7 shows the test setup for fast transients according IEC 61000-4-4.
Fast transients (burst)
Working Draft
61131-9/WD V0.5 IEC
– 244 –
Power Supply
CDN
AUX 1 (Master)
D=0,3 m
AUX 2 (Device)
l = 0,5 m
4443 4444
EUT (Device)
CCC
l = 0,5 m
Figure G.7 – Test setup for fast transients (Device)
4445
NOTE 1
CDN: Coupling/Decoupling Network, here only used for decoupling
4446
NOTE 2
CCC: Capacitive coupling clamp
4447
G.2.7.5
4448
Figure G.8 shows the test setup for radio-frequency common mode according IEC 61000-4-6.
Radio-frequency common mode
Power Supply
CDN
AUX 1 (Master)
x
4449 4450
DUT (Device)
EM-Clamp
x
x
Figure G.8 – Test setup for RF common mode (Device)
4451
NOTE 1
0,1 m < x < 0,3 m
4452
NOTE 2
SDCI overall cable length = 1 m
4453
G.3
4454
G.3.1
4455
Detailed instructions for the Master and Device tests are specified in [14].
4456
G.3.2
4457 4458 4459
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.
4460
G.3.3
4461 4462 4463 4464 4465 4466 4467 4468
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.
4469 4470
NOTE A deviation of sent and received Process Data indicates to the AUX1 that the EUT (Master) did not receive the Device message.
Test strategies for conformity General
Test of a Device
Test of a Master
61131-9/WD V0.5 IEC
– 245 –
Working Draft
4471
G.4
4472
Figure G.9 shows a layout proposal for a manufacturer's declaration of conformity.
Manufacturer declaration
(Consortium logo)
WE:
MANUNFACTURER'S DECLARATION OF CONFORMITY
(Company logo)
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, 2010
IO Device Description, V1.1, 2010
IEC 61000-6-2 (IEC 61131-2)
IEC 60947-5-2
(see NOTE 1)
(see NOTE 2)
The conformity tests are documented in the test report: Testreport identification Issued at location, date
Authorized signatory
Name:
First, last name
Title:
Job title
Signature:
Signature
Reproduction and all distribution without written authorization prohibited 4473 4474 4475
NOTE 1
Relevant EMC standards in case of a Master
NOTE 2
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
61131-9/WD V0.5 IEC
– 246 –
Annex H (informative) Residual error probabilities
4479
H.1
4480 4481 4482 4483
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).
Residual error probability of the SDCI data integrity mechanism
1 0,1
Integrity class I2
0,01
Residual error probability (R)
1* 10-3 1* 10-4 1* 10-5 1* 10-6
Hamming distance 4
1* 10-7 1* 10-8 1* 10-9 Key
1* 10-10 1*
SDCI with 2 octets SDCI with 3 octets SDCI with 4 octets
10-11
1* 10-12 1* 10-13
1* 10-4
1* 10-3
0,01
0,1
1
Bit error probability (BEP)
4484 4485
Figure H.1 – Residual error probability for the SDCI data integrity mechanism
4486 4487 4488
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.
4489
H.2
4490 4491
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):
4492
Only 1 undetected erroneous frame in 20 years at 1 600 frames/s
4493
The ratio of undetected to detected frames shall not exceed 10 -6
4494
EMC tests shall not show more than 6 erroneous frames within 100 000 frames
4495 4496
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.
Derivation of EMC test conditions
61131-9/WD V0.5 IEC
– 247 –
F20 R(BEP ) 1
Working Draft
(H.1)
4497
The Terms in equation (H.1) are:
4498
F20
= Number of frames in 20 years
4499
R(BEP)
= Residual error probability of the checksum and parity mechanism (Figure H.1)
4500
BEP
= Bit error probability from Figure H.1
4501 4502 4503 4504 4505
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
1 1 NopErr BEP BitPerF
(H.2)
4506
The Terms in equation (H.2) are:
4507
NoTF
= Number of test frames
4508
BitPerF
= Number of bit per frame
4509
NopErr
= Maximum number of detected perturbed frames = 6
4510 4511 4512 4513
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
61131-9/WD V0.5 IEC
– 248 –
4514 4515 4516
Annex I ( informative) Example sequence of an ISDU transmission
4517 4518 4519
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.
4520 Master
Device
FC comment
cycle
(state, action) (see in Table 46)
4522
Com Flow Frame CHK
nr W Chan. CTRL Typ 1bit 2bit 5bit 2bit
6bit
PD Process Data 8bit
1111 0001 0111 0000 0110 0001 0110 0010 0110 0011 0110 0100 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000
10 10 10 10 10 10 10 10 10 10 10
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
19
1111 0000 1110 0001 1110 0010 1110 0011 1110 0100 1110 0101 1110 0110 1110 0111 1110 1000
10 10 10 10 10 10 10 10 10
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
20
1110 1001
10
Err
xxxxxxxx
21
1110 1001 1110 1001 1110 1010
10 Err 10 xxxxxx 10 xxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx
Idle_1
0
ISDURequest_2, transmission,
1
ISDURequest_2, transmission
2
ISDURequest_2, transmission
3
ISDURequest_2, transmission
4
ISDURequest_2, transmission
5
ISDUWait_3, start ISDU Timer
6
ISDUWait_3, inc. ISDU timer
7
ISDUWait_3, inc. ISDU timer
8
ISDUWait_3, inc. ISDU timer
9
ISDUWait_3, inc. ISDU timer ISDUResponse_4, reception Stop ISDU Timer
10
ISDUResponse_4, reception
12
ISDUResponse_4, reception
13
ISDUResponse_4, reception
14
ISDUResponse_4, reception
15
ISDUResponse_4, reception
16
ISDUResponse_4, reception
17
ISDUResponse_4, reception
18
ISDUResponse_4, reception ISDUResponse_4, no response, retry in next cycle ISDUResponse_4, no response, retry in next cycle ISDUResponse_4, reception
22
ISDUResponse_4, reception
34
11
ISDUResponse_4, reception, start eventhandler
35
1110 1011
10 xxxxxx
xxxxxxxx
Read_Event_2, reception
36
1100 0000
10 xxxxxx
xxxxxxxx
Read_Event_2, reception
37
110x xxxx
10 xxxxxx
xxxxxxxx
Command handler_2, transmission set PDOutdata state to invalid 38
4521
R
CKT
0010 0000
10 xxxxxx
xxxxxxxx
Read_Event_2, reception
39
110x xxxx
10 xxxxxx
xxxxxxxx
Read_Event_2, reception EventConfirmation_4, transmission, event handler idle
40
110x xxxx
10 xxxxxx
xxxxxxxx
41
ISDUResponse_4, reception
42
ISDUResponse_4, reception
43
ISDUResponse_4, reception
44
ISDUResponse_4, reception
45
ISDUResponse_4, reception
46
ISDUResponse_4, reception
47
ISDUResponse_4, reception
48
Idle_1
49
Idle_1
50
Idle_1
51
Idle_1
52
Write Parameter, transmission
53
Read Parameter, reception
54
Idle_1
55
Idle_1
56
Idle_1
57
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
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
OD
OD
OnReq Data Master 8bit
Device
PD
CKS
Process Data
CHK E PD
comment (state, action)
8bit
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
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
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
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
Data 8 Data 9 Data 10 Diag State with detail Event qualifier
1001 1001 ErrorCode msb ErrorCode lsb
xxxxxxxx Data 11 Data 12 Data 13 Data 14 Data 15 Data 16 CHKPDU
0000 0000 0000 0000 0000 0000 0000 0000 xxxxxxxx xxxxxxxx 0000 0000 0000 0000 0000 0000
xxxxxxxx xxxxxxxx
xxxxxx 0 0 xxxxxx 0 0 xxxxxx
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
xxxxxxxx
1 0 xxxxxx
ISDUResponse_4, transmission, freeze event
xxxxxxxx
1 0 xxxxxx
Read_Event_2, transmission
xxxxxxxx
1 0 xxxxxx
Read_Event_2, transmission
xxxxxxxx
1 0 xxxxxx
ComandHandler_2, reception, set PDOutdata state to invalid
xxxxxxxx
1 0 xxxxxx
Read_Event_2, transmission
xxxxxxxx
1 0 xxxxxx
Read_Event_2, transmission
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
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
Figure I.1 – Example for ISDU transmissions
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
61131-9/WD V0.5 IEC
4523 4524
ISDURequest_2, transmission
58
ISDURequest_2, transmission
59
ISDURequest_2, transmission
60
ISDURequest_2, transmission
61
ISDURequest_2, transmission
62
ISDURequest_2, transmission
63
ISDURequest_2, transmission
64
ISDURequest_2, transmission
65
ISDURequest_2, transmission
66
ISDURequest_2, transmission
67
ISDURequest_2, transmission
68
ISDUWait_3, start ISDU Timer ISDUResponse_4, reception Stop ISDU Timer
69 70
ISDUResponse_4, reception
71
Idle_1
72
Idle_1
73
ISDURequest_2, transmission,
74
ISDURequest_2, transmission
75
ISDURequest_2, transmission
76
ISDURequest_2, transmission
77
ISDURequest_2, transmission
78
ISDUWait_3, start ISDU Timer
79
ISDUWait_3, inc. ISDU timer
80
ISDUWait_3, inc. ISDU timer
81
ISDUWait_3, inc. ISDU timer
82
ISDUWait_3, inc. ISDU timer ISDUResponse_4, reception Stop ISDU Timer
83
ISDUResponse_4, reception
85
ISDUResponse_4, reception
86
ISDUResponse_4, ABORT
87
Idle_1 Idle_1
88 89
84
– 249 –
0111 0000 0110 0001 0110 0010 0110 0011 0110 0100 0110 0101 0110 0110 0110 0111 0110 1000 0110 1001 0110 1010 1111 0000
10 10 10 10 10 10 10 10 10 10 10 10
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
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
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
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
1111 0000 1110 0001 1110 0010 1111 1111 1111 0001 1111 0001
10 10 10 10 10 10
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
Working Draft
0001 1011 Index Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8 CHKPDU
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
0000 0000 0000 0000 0000 0000
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
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
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
ISDUResponse_4, transmission
xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
0 0 0 0 0 0
0 0 0 0 0 0
xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx xxxxxx
ISDUResponse_4, transmission
Figure I.2 – Example for ISDU transmissions (continued)
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 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, ABORT Idle_1 Idle_1
Working Draft 4525 4526 4527
– 250 –
61131-9/WD V0.5 IEC
Annex J ( informative) Recommended methods for detecting parameter changes
4528
J.1
4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539 4540
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.
4541
Table J.1 – Proper CRC generator polynomials
CRC signature
Generator polynomial
Signature
Data length
Undetected changes
0x9B
8 bit
1 octet
< 2 -8 (not recommended)
0x4EAB
16 bit
1 < octets < 3
< 2 -16 (not recommended)
0x5D6DCB
24 bit
1 < octets < 4
< 2 -24 (not recommended)
0xF4ACFB13
32 bit
1 < octets < 2 32
< 2 -32 (recommended)
4542 4543
J.2
4544 4545 4546 4547 4548 4549
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.
4550 4551
Revision counter
61131-9/WD V0.5 IEC
– 251 –
Working Draft
4552 4553 4554
Annex K (informative) Information on conformity testing of SDCI
4555 4556
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:
4557 4558 4559 4560 4561 4562 4563 4564 4565
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:
[email protected] Web site: http://www.io-link.com
Working Draft
– 252 –
61131-9/WD V0.5 IEC
4566
Bibliography
4567 4568 4569 4570 4571
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.
4572 4573
The examples provided below include automatic numbering of the documents, using a dedicated caption label “Reference” (for easy update and referencing within the text).
4574
If this caption label is not known in your environment, you can add it as follows:
4575
1) Put your cursor on a new line
4576 4577
2) From the main menu, select “Insert – Reference - Caption”, then select “New label”, then enter the string “Reference” as new label, then OK twice.
4578 4579
3) Delete the (un-useful) line that was just created (the new label will still be remembered).
4580 4581 4582 4583
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.
4584
[1] IEC 60050 (all parts), International Electrotechnical Vocabulary
4585 4586
NOTE See also the IEC Multilingual Dictionary – Electricity, Electronics and Telecommunications (available on CD-ROM and at ).
4587 4588
[2] IEC/TR 62453-61, Field device tool interface specification – Device Type Manager (DTM) Styleguide for common object model
4589
[3] IO-Link Consortium, IO Device Description (IODD), V1.0, Order No. 10.012
4590
[4] IEC/TR 62390: 2005, Common automation device profile guideline
4591 4592
[5] ISO/IEC DIS 19505:2009 Information technology – OMG Unified Modeling Language (OMG UML) Version 2.1.2
4593 4594
[6] IEC 60870-5-1:1990, Telecontrol equipment and systems. Part 5: Transmission protocols - Section One: Transmission frame formats
4595
[7] "The Unicode Standard", V5.0
4596 4597
[8] Internet Engineering Task Force (IETF): RFC 1305 – Network Time Protocol (Version 3) Specification, Implementation and Analysis; available at < www.ietf.org >
4598 4599
[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
4600
[10] ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic
4601 4602
[11] ISO/IEC 646:1991, Information technology – ISO 7-bit coded character set for information interchange
4603
[12] IO-Link Consortium, IO-Link Device Profiles, Vx.y 4
4604
[13] IO-Link Consortium, IO-Link Communication, V1.0, January 2009, Order No. 10.002
4605
[14] IO-Link Consortium, IO-Link Test Specification, Vx.y 4
4606 4607
[15] Adrian Farrel, The Internet and its Protocols: A Comparative Approach, Morgan Kaufmann, ISBN-13 978-1558609136
4608
[16] NE107, Self-Monitoring and Diagnosis of Field Devices, June 2006, ____________
4609
————————— 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:
[email protected] http://www.io-link.com/
