IO-Link Safety System-Extensions 10092 V10 Apr17

IO-Link Safety
System Extensions
Specification
Version 1.0
April 2017
Order No: 10.092

IO-Link Safety – System Extensions V1.0
_________________________________________________________________________________________________________
File name: IO-Link_Safety_System-Extensions_10092_V10_Apr17.doc

This specification has been prepared by the IO-Link Safety technology subgroup. It achieved a
concept approval by TÜV-SÜD.
Any comments, proposals, requests on this document are appreciated through the IO-Link CR
database www.io-link-projects.com. Please provide name and email address.
Login: IOL-Safety10
Password: Report
Important notes:
NOTE 1 The IO-Link Community 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 Community
specifications may require use of an invention covered by patent rights. The IO-Link Community shall not be
responsible for identifying patents for which a license may be required by any IO-Link Community specification, or
for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. IO-
Link Community 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 Community 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 IO-
LINK COMMUNITY 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 Community 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
Community. More detailed terms for the use can be found in the IO-Link Community 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 Community
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 Community 2017 - All Rights Reserved Page 2 of 160

IO-Link Safety –3– V1.0
CONTENTS
0 Introduction ................................................................................................................... 12
0.1 General ................................................................................................................. 12
0.2 Patent declaration ................................................................................................. 13
1 Scope ............................................................................................................................ 14
2 Normative references .................................................................................................... 15
3 Terms, definitions, symbols, abbreviated terms and conventions ................................... 16
3.1 Common terms and definitions .............................................................................. 16
3.2 IO-Link Safety: Additional terms and definitions .................................................... 19
3.3 Symbols and abbreviated terms ............................................................................ 20
3.4 Conventions .......................................................................................................... 21
3.4.1 Behavioral descriptions.................................................................................. 21
3.4.2 Memory and transmission octet order ............................................................ 21
4 Overview of IO-Link Safety ............................................................................................ 22
4.1 Purpose of the technology and feature levels ........................................................ 22
4.1.1 Base IO-Link Safety technology ..................................................................... 22
4.1.2 From "analog" and "switching" to communication ........................................... 23
4.1.3 Minimized paradigm shift from FS-DI to FS-Master ........................................ 24
4.1.4 Following the IO-Link paradigm (SIO vs. OSSDe) .......................................... 24
4.1.5 Port class B (Classic and Combi) ................................................................... 26
4.1.6 "USB-Master" with safety parameterization .................................................... 27
4.1.7 Interoperability matrix of safety devices ......................................................... 27
4.2 Positioning within the automation hierarchy .......................................................... 28
4.3 Wiring, connectors, and power supply ................................................................... 29
4.4 Relationship to IO-Link ......................................................................................... 29
4.5 Communication features and interfaces ................................................................ 29
4.6 Parameterization ................................................................................................... 29
4.7 Role of FS-Master and FS-Gateway ...................................................................... 30
4.8 Mapping to upper level systems ............................................................................ 30
4.9 Structure of the document ..................................................................................... 30
5 Extensions to the Physical Layer (PL)............................................................................ 31
5.1 Overview .............................................................................................................. 31
5.2 Extensions to PL services ..................................................................................... 31
5.2.1 PL_SetMode .................................................................................................. 31
5.2.2 PL_Ready ...................................................................................................... 31
5.3 Transmitter/receiver .............................................................................................. 32
5.3.1 Assumptions for the expansion to OSSDe ...................................................... 32
5.3.2 OSSDe specifics ............................................................................................ 32
5.3.3 Start-up of an FS-Device (Ready pulse) ......................................................... 35
5.3.4 Electric characteristics of a receiver in FS-Device and FS-Master.................. 35
5.4 Electric and dynamic characteristics of an FS-Device ........................................... 36
5.5 Electric and dynamic characteristics of an FS-Master port (OSSDe) ..................... 38
5.6 FS-Master port FS-DI interface ............................................................................. 39
5.7 Wake-up coordination ........................................................................................... 40
5.8 Fast start-up ......................................................................................................... 40
5.9 Power supply ........................................................................................................ 40
5.10 Medium ................................................................................................................. 41

5.10.1 Constraints .................................................................................................... 41
5.10.2 Connectors .................................................................................................... 41
5.10.3 Cable characteristics ..................................................................................... 41
6 Extensions to SIO .......................................................................................................... 41
7 Extensions to data link layer (DL) .................................................................................. 41
7.1 Overview .............................................................................................................. 41
7.2 State machine of the FS-Master DL-mode handler ................................................ 41
7.3 State machine of the FS-Device DL-mode handler ................................................ 43
8 Extensions to system management (SM) ....................................................................... 44
9 Extensions of the FS-Device .......................................................................................... 44
9.1 Principle architecture and models ......................................................................... 44
9.1.1 FS-Device architecture .................................................................................. 44
9.1.2 FS-Device model ........................................................................................... 44
9.2 Parameter Manager (PM) ...................................................................................... 45
9.3 Process Data Exchange (PDE) ............................................................................. 45
9.4 Data Storage (DS) ................................................................................................ 45
9.4.1 General considerations including safety ......................................................... 45
9.4.2 User point of view .......................................................................................... 46
9.4.3 Operations and preconditions for Device replacement ................................... 46
9.4.4 Commissioning .............................................................................................. 47
9.4.5 Backup Levels ............................................................................................... 47
9.4.6 Use cases ..................................................................................................... 50
10 Extensions of the FS-Master .......................................................................................... 51
10.1 Principle architecture ............................................................................................ 51
10.2 Safety Layer Manager (SLM) ................................................................................ 51
10.2.1 Purpose ......................................................................................................... 51
10.2.2 FS_PortModes ............................................................................................... 51
10.2.3 FSP parameter blocks ................................................................................... 52
10.3 Process Data Exchange (PDE) ............................................................................. 54
10.4 Data Storage (DS) ................................................................................................ 54
11 Safety communication layer (SCL) ................................................................................. 55
11.1 Functional requirements........................................................................................ 55
11.2 Communication faults and safety measures .......................................................... 55
11.3 SCL services ........................................................................................................ 56
11.3.1 Positioning of safety communication layers (SCL) .......................................... 56
11.3.2 FS-Master SCL services ................................................................................ 56
11.3.3 FS-Device SCL services ................................................................................ 58
11.4 SCL protocol ......................................................................................................... 59
11.4.1 Protocol phases to consider ........................................................................... 59
11.4.2 FS-Device faults ............................................................................................ 60
11.4.3 Safety PDU (SPDU) ....................................................................................... 60
11.4.4 FS-Input and FS-Output data ......................................................................... 60
11.4.5 Status and control ......................................................................................... 61
11.4.6 CRC signature ............................................................................................... 61
11.4.7 Data types for IO-Link Safety ......................................................................... 62
11.5 SCL behavior ........................................................................................................ 64
11.5.1 General ......................................................................................................... 64
11.5.2 SCL state machine of the FS-Master ............................................................. 64

11.5.3 SCL state machine of the FS-Device ............................................................. 66
11.5.4 Sequence charts for several use cases .......................................................... 69
11.5.5 Monitoring of safety times .............................................................................. 75
11.5.6 Reaction in the event of a malfunction ........................................................... 75
11.5.7 Start-up (communication)............................................................................... 78
11.6 SCL management ................................................................................................. 78
11.6.1 Parameter overview (FSP and FST) ............................................................... 78
11.6.2 Parameterization approaches ........................................................................ 79
11.7 Integrity measures ................................................................................................ 80
11.7.1 IODD integrity ................................................................................................ 80
11.7.2 Tool integrity ................................................................................................. 80
11.7.3 Transmission integrity .................................................................................... 80
11.7.4 Verification and validation .............................................................................. 81
11.7.5 Authenticity ................................................................................................... 81
11.7.6 Storage integrity ............................................................................................ 81
11.7.7 FS I/O data structure integrity ........................................................................ 82
11.7.8 Technology parameter (FST) based on IODD ................................................ 82
11.7.9 Technology parameter (FST) based on existing dedicated tool (IOPD) .......... 83
11.8 Creation of FSP and FST parameters ................................................................... 84
11.9 Integration of dedicated tools (IOPD) .................................................................... 85
11.9.1 IOPD interface ............................................................................................... 85
11.9.2 Standard interfaces ....................................................................................... 85
11.9.3 Backward channel ......................................................................................... 86
11.10 Passivation ........................................................................................................... 86
11.10.1 Motivation and means .................................................................................... 86
11.10.2 Port selective (FS-Master) ............................................................................. 87
11.10.3 Signal selective (FS-Terminal) ....................................................................... 87
11.10.4 Qualifier settings in case of communication ................................................... 87
11.10.5 Qualifier handling in case of OSSDe .............................................................. 87
11.11 SCL diagnosis....................................................................................................... 89
12 Functional safe processing (FS-P) ................................................................................. 89
12.1 Recommendations for efficient I/O mappings ........................................................ 89
12.2 FS logic control ..................................................................................................... 89
Annex A (normative, safety-related) Extensions to parameters ............................................ 90
A.1 Indices and parameters for IO-Link Safety ............................................................ 90
A.2 Parameters in detail .............................................................................................. 91
A.2.1 FSCP_Authenticity......................................................................................... 91
A.2.2 FSP_Port ....................................................................................................... 91
A.2.3 FSP_AuthentCRC .......................................................................................... 91
A.2.4 FSP_ProtVersion ........................................................................................... 91
A.2.5 FSP_ProtMode .............................................................................................. 92
A.2.6 FSP_Watchdog .............................................................................................. 92
A.2.7 FSP_TechParCRC ......................................................................................... 92
A.2.8 FSP_ProtParCRC .......................................................................................... 92
A.2.9 FSP_IO_StructCRC ....................................................................................... 92
A.2.10 FS_Password ................................................................................................ 93
A.2.11 Reset_FS_Password ..................................................................................... 94
A.2.12 FSP_ParamDescCRC .................................................................................... 94
Annex B (normative, non-safety related) Extensions to EventCodes .................................... 95

B.1 Additional EventCodes .......................................................................................... 95
Annex C (normative, safety related) Extensions to Data Types ............................................ 96
C.1 Data types for IO-Link Safety ................................................................................ 96
C.2 BooleanT (bit) ....................................................................................................... 96
C.3 IntegerT (16) ......................................................................................................... 97
C.4 IntegerT (32) ......................................................................................................... 97
C.5 Safety Code .......................................................................................................... 98
Annex D (normative, safety related) CRC generator polynomials ......................................... 99
D.1 Overview of CRC generator polynomials ............................................................... 99
D.2 Residual error probabilities ................................................................................... 99
D.3 Implementation considerations ............................................................................ 101
D.3.1 Overview ..................................................................................................... 101
D.3.2 Bit shift algorithm (16 bit) ............................................................................. 101
D.3.3 Lookup table (16 bit) .................................................................................... 101
D.3.4 Bit shift algorithm (32 bit) ............................................................................. 102
D.3.5 Lookup table (32 bit) .................................................................................... 103
D.3.6 Seed values ................................................................................................. 104
Annex E (normative, safety related) IODD extensions ........................................................ 105
E.1 General ............................................................................................................... 105
E.2 Schema .............................................................................................................. 105
E.3 IODD constraints ................................................................................................ 105
E.3.1 Overview and general rules ......................................................................... 105
E.3.2 Specific SystemCommands ......................................................................... 106
E.3.3 Profile Characteristic ................................................................................... 106
E.3.4 ProcessDataInput and ProcessDataOutput .................................................. 106
E.4 IODD conventions ............................................................................................... 106
E.4.1 Naming ........................................................................................................ 106
E.4.2 Process Data (PD) ....................................................................................... 107
E.4.3 IODD conventions for user interface ............................................................ 107
E.4.4 Master Tool features .................................................................................... 107
E.5 Securing ............................................................................................................. 108
E.5.1 General ....................................................................................................... 108
E.5.2 DefaultValues for FSP ................................................................................. 108
E.5.3 FSP_Authenticity ......................................................................................... 109
E.5.4 FSP_Protocol .............................................................................................. 109
E.5.5 FSP_IO_Description .................................................................................... 109
E.5.6 Sample serialization for FSP_ParamDescCRC ............................................ 109
E.5.7 FST and FSP parameters and Data Storage ................................................ 111
E.5.8 Sample IODD of an FS-Device..................................................................... 111
Annex F (normative, non-safety related) Device Tool Interface (DTI) for IO-Link ................ 119
F.1 Purpose of DTI.................................................................................................... 119
F.2 Base model ......................................................................................................... 119
F.3 Invocation interface............................................................................................. 120
F.3.1 Overview ..................................................................................................... 120
F.3.2 Detection of Device Tool .............................................................................. 120
F.3.3 Program Interface Description – PID ............................................................ 123
F.3.4 Temporary Parameter File – TPF ................................................................. 126
F.3.5 Temporary Backchannel File – TBF ............................................................. 131

F.3.6 Temporary Acknowledgment File – TAF ....................................................... 133
F.3.7 Invocation behavior ..................................................................................... 134
F.4 Device data objects (DDO) .................................................................................. 134
F.4.1 General ....................................................................................................... 134
F.4.2 Creating DDOs ............................................................................................ 134
F.4.3 Copying DDOs ............................................................................................. 136
F.4.4 Moving DDOs .............................................................................................. 136
F.4.5 Deleting DDOs ............................................................................................. 136
F.5 Communication Interface .................................................................................... 136
F.5.1 General ....................................................................................................... 136
F.5.2 Principle of DTI communications .................................................................. 137
F.5.3 Gateways .................................................................................................... 139
F.5.4 Configuration of the Communication Server ................................................. 139
F.5.5 Definition of the Communication Interface .................................................... 139
F.5.6 Sequence for establishing a communication relation .................................... 139
F.5.7 Usage of the Communication Server in stand-alone mode ........................... 140
F.5.8 IO-Link specifics .......................................................................................... 141
F.5.9 Changing communication settings................................................................ 142
F.6 Reaction on incorrect Tool behavior .................................................................... 142
F.7 Compatibility ....................................................................................................... 142
F.7.1 Schema validation ....................................................................................... 142
F.7.2 Version policy .............................................................................................. 143
F.8 Scalability ........................................................................................................... 143
F.8.1 Scalability of a Device Tool.......................................................................... 143
F.8.2 Scalability of a Master Tool.......................................................................... 144
F.8.3 Interactions at conformance class combinations .......................................... 144
F.9 Schema definitions ............................................................................................. 144
F.9.1 General ....................................................................................................... 144
F.9.2 Schema of the PID....................................................................................... 144
F.9.3 Schema of the TPF ...................................................................................... 146
F.9.4 Schema of the TBF ...................................................................................... 148
F.9.5 Schema of the TAF ...................................................................................... 149
F.9.6 Schema of DTI primitives ............................................................................. 149
Annex G (normative) Main scenarios of IO-Link Safety ...................................................... 152
Annex H (normative) System requirements ........................................................................ 153
H.1 Indicators ............................................................................................................ 153
H.1.1 General ....................................................................................................... 153
H.1.2 OSSDe ........................................................................................................ 153
H.1.3 Safety communication ................................................................................. 153
H.1.4 Acknowledgment request ............................................................................. 153
H.2 Installation guidelines, electrical safety, and security .......................................... 153
H.3 Safety function response time ............................................................................. 154
H.4 Duration of demands ........................................................................................... 154
H.5 Maintenance and repair ...................................................................................... 154
H.6 Safety manual ..................................................................................................... 154
Annex I (normative) Assessment ........................................................................................ 155
I.1 General ............................................................................................................... 155
I.2 Safety policy ....................................................................................................... 155
I.3 Obligations ......................................................................................................... 155

I.4 Concept approval ................................................................................................ 155
Annex J (normative) Details of "Classic" port class B ......................................................... 156
J.1 "Classic" power supply option ............................................................................. 156
J.2 Rules .................................................................................................................. 157
Annex K (normative) Test of FS-Master and FS-Device ..................................................... 158
Bibliography ...................................................................................................................... 159
Figure 1 – Relationship of this document to standards .......................................................... 12

Figure 2 – IO-Link Safety on single platform ......................................................................... 14
Figure 3 – Memory and transmission octet order ................................................................... 22
Figure 4 – IO-Link Safety communication layer model ........................................................... 22
Figure 5 – Port interface extensions for IO-Link Safety ......................................................... 23
Figure 6 – Migration to IO-Link Safety ................................................................................... 23
Figure 7 – Minimized paradigm shift from FS-DI to FS-Master .............................................. 24
Figure 8 – FS-Master types and feature levels ...................................................................... 25
Figure 9 – Original pin layout of IO-Link (port class A) .......................................................... 25
Figure 10 – Optimized OSSDe commissioning with FS-Master .............................................. 26
Figure 11 – Level "d" of an FS-Master (Combi – class B) ...................................................... 27
Figure 12 – Off-site configuration and parameterization ........................................................ 27
Figure 13 – IO-Link Safety within the automation hierarchy ................................................... 28
Figure 14 – The IO-Link physical layer of an FS-Master (class A) ......................................... 31
Figure 15 – The IO-Link physical layer of an FS-Device (class A) ......................................... 31
Figure 16 – Cross compatibility OSSD and OSSDe ............................................................... 32
Figure 17 – Principle OSSDe function ................................................................................... 33
Figure 18 – Test pulses to detect cross connection faults ..................................................... 34
Figure 19 – OSSD timings .................................................................................................... 34
Figure 20 – Typical start-up of an OSSD sensor ................................................................... 35
Figure 21 – Start-up of an FS-Device .................................................................................... 35
Figure 22 – Switching thresholds for FS-Device and FS-Master receivers ............................. 36
Figure 23 – Reference schematics (one OSSDe channel) ..................................................... 36
Figure 24 – Voltage level definitions ..................................................................................... 37
Figure 25 – Charge capability at power-up ............................................................................ 39
Figure 26 – OSSDe input filter conflict resolution .................................................................. 40
Figure 27 – Start-up of an FS-Device .................................................................................... 40
Figure 28 – Required fast start-up timings ............................................................................ 40
Figure 29 – State machine of the FS-Master DL-mode handler ............................................. 42
Figure 30 – State machine of the FS-Device DL-mode handler ............................................. 43
Figure 31 – Principle architecture of the FS-Device .............................................................. 44
Figure 32 – The FS-Device model ......................................................................................... 45
Figure 33 – Active and backup parameter ............................................................................. 47
Figure 34 – Off-site commissioning ....................................................................................... 47
Figure 35 – Principle architecture of the FS-Master .............................................................. 51
Figure 36 – FSP parameter use cases .................................................................................. 52
Figure 37 – Positioning of the IO-Link Safety Communication Layer (SCL) ........................... 56

Figure 38 – FS-Master Safety Communication Layer services ............................................... 57
Figure 39 – FS-Device Safety Communication Layer services ............................................... 58
Figure 40 – Protocol phases to consider ............................................................................... 59
Figure 41 – Safety PDUs of FS-Master and FS-Device ......................................................... 60
Figure 42 – The 1 % share rule of IEC 61784-3 .................................................................... 62
Figure 43 – SCL state machine of the FS-Master .................................................................. 64
Figure 44 – SCL state machine of the FS-Device .................................................................. 66
Figure 45 – FS-Master and FS-Device both with power ON ................................................... 69
Figure 46 – FS-Master power OFF  ON ............................................................................. 70
Figure 47 – FS-Device with delayed SCL start ...................................................................... 71
Figure 48 – FS-Device with power OFF and ON .................................................................... 72
Figure 49 – FS-Master detects CRC signature error .............................................................. 73
Figure 50 – FS-Device detects CRC signature error .............................................................. 74
Figure 51 – Monitoring of the SCL cycle time ........................................................................ 75
Figure 52 – Parameter types and assignments...................................................................... 79
Figure 53 – FSCP-Host-centric system ................................................................................. 80
Figure 54 – Structure of the protocol parameter (FSP) record ............................................... 81
Figure 55 – Start-up of IO-Link safety ................................................................................... 82
Figure 56 – Securing of FST parameters via dedicated tool .................................................. 83
Figure 57 – Modification of FST parameters via Device Tool ................................................. 83
Figure 58 – Creation of FSP and FST parameters ................................................................. 84
Figure 59 – Example of a communication hierarchy .............................................................. 85
Figure 60 – Motivation for Port selective passivation ............................................................. 86
Figure 61 – Qualifier handler (communication) ...................................................................... 87
Figure 62 – Qualifier handler (OSSDe).................................................................................. 88
Figure 63 – Qualifier behavior per FS-Master port ................................................................ 88
Figure 64 – Mapping efficiency issues .................................................................................. 89
Figure A.1 – Instance of an FS I/O data description .............................................................. 93
Figure A.2 – Example FS I/O data structure with non-safety data .......................................... 93
Figure A.3 – Securing of safety parameters .......................................................................... 94
Figure C.1 – Example of a BooleanT data structure .............................................................. 96
Figure C.2 – Safety Code of an output message ................................................................... 98
Figure C.3 – Safety Code of an input message ..................................................................... 98
Figure D.1 – CRC-16 generator polynomial ......................................................................... 100
Figure D.2 – CRC-32 generator polynomial ......................................................................... 100
Figure D.3 – Bit shift algorithm in "C" language (16 bit) ....................................................... 101
Figure D.4 – CRC-16 signature calculation using a lookup table ......................................... 101
Figure D.5 – Bit shift algorithm in "C" language (32 bit) ....................................................... 103
Figure D.6 – CRC-32 signature calculation using a lookup table ......................................... 103
Figure E.1 – Algorithm to build the FSP parameter CRC signatures .................................... 108
Figure F.1 – Principle of DTI invocation interface ................................................................ 120
Figure F.2 – Structure of the registry .................................................................................. 121
IO-Link Safety – 10 – V1.0
Figure F.3 – Example of a DTI registry ................................................................................ 121

Figure F.4 – Detection of a Device Tool in registry .............................................................. 123
Figure F.5 – Menu for Device Tool invocation ..................................................................... 124
Figure F.6 – Structure of the PID file ................................................................................... 124
Figure F.7 – Structure of a TPF .......................................................................................... 127
Figure F.8 – Structure of the TBF........................................................................................ 132
Figure F.9 – Activity diagram for the DDO handling ............................................................. 135
Figure F.10 – Communication routes between Device Tool and Device ............................... 137
Figure F.11 – Routing across networks and IO-Link ............................................................ 138
Figure F.12 – Communication Server .................................................................................. 138
Figure F.13 – Sequence chart for establishing communication ............................................ 140
Figure F.14 – Create Communication Server instance......................................................... 140
Figure F.15 – Example of a Connect Request XML document for IO-Link ............................ 141
Figure F.16 – XML schema of the PID file ........................................................................... 144
Figure F.17 – XML schema of the TPF ................................................................................ 146
Figure F.18 – XML schema of a TBF ................................................................................... 148
Figure J.1 – "Classic" port Class B definitions ..................................................................... 156
Figure J.2 – Possible layout of cable with Power1 and Power2 ........................................... 157
Table 1 – Operational modes of feature level "a" to "c" (port class A).................................... 26
Table 2 – Interoperability matrix of safety devices ................................................................. 27
Table 3 – PL_Ready ............................................................................................................. 31
Table 4 – OSSD states and conditions .................................................................................. 33
Table 5 – Cross connection faults ......................................................................................... 33
Table 6 – Electric characteristics of a receiver ...................................................................... 35
Table 7 – Electric and dynamic characteristics of the FS-Device (OSSDe) ............................ 37
Table 8 – Electric and dynamic characteristics of the Port interface ...................................... 38
Table 9 – Cable characteristics ............................................................................................. 41
Table 10 – State transition tables of the FS-Master DL-mode handler ................................... 42
Table 11 – State transition tables of the FS-Device DL-mode handler ................................... 43
Table 12 – Recommended Data Storage Backup Levels ....................................................... 48
Table 13 – Criteria for backing up parameters ("Backup/Restore") ........................................ 49
Table 14 – Criteria for backing up parameters ("Restore") .................................................... 49
Table 15 – Use case reference table ..................................................................................... 52
Table 16 – Communication errors and safety measures ........................................................ 55
Table 17 – SCL services of FS-Master .................................................................................. 57
Table 18 – SCL services of FS-Device .................................................................................. 58
Table 19 – Protocol phases to consider ................................................................................ 59
Table 20 – Control and counting (Control&MCnt) .................................................................. 61
Table 21 – Status and counting mirror (Status&DCnt) ........................................................... 61
Table 22 – MCount and DCount_i values .............................................................................. 61
Table 23 – FS process I/O data types ................................................................................... 63
Table 24 – Rules for the layout of values and qualifiers ........................................................ 63
Table 25 – Order of values and qualifier ............................................................................... 63

Table 26 – Definition of terms used in SCL state machine of the FS-Master .......................... 64
Table 27 – FS-Master SCL states and transitions ................................................................. 64
Table 28 – Definition of terms used in SCL state machine of the FS-Device .......................... 66
Table 29 – FS-Device SCL states and transitions ................................................................. 67
Table 30 – Timing constraints ............................................................................................... 75
Table 31 – Qualifier bits "GOOD/BAD" .................................................................................. 87
Table 32 – State transition table for the qualifier behavior ..................................................... 88
Table A.1 – Indices for IO-Link Safety ................................................................................... 90
Table A.2 – Coding of protocol version ................................................................................. 91
Table A.3 – Coding of protocol mode .................................................................................... 92
Table A.4 – Generic FS I/O data structure description .......................................................... 93
Table B.1 – SCL specific EventCodes ................................................................................... 95
Table C.1 – Data types for IO-Link Safety ............................................................................. 96
Table C.2 – BooleanT for IO-Link Safety ............................................................................... 96
Table C.3 – Example of BooleanT within a RecordT .............................................................. 96
Table C.4 – IntegerT(16) ....................................................................................................... 97
Table C.5 – IntegerT(16) coding ........................................................................................... 97
Table C.6 – IntegerT(32) ....................................................................................................... 97
Table C.7 – IntegerT(32) coding ........................................................................................... 97
Table D.1 – CRC generator polynomials for IO-Link Safety ................................................... 99
Table D.2 – Definition of variables used in Figure D.3 ......................................................... 101
Table D.4 – Lookup table for CRC-16 signature calculation ................................................ 102
Table D.7 – Lookup table for CRC-32 signature calculation ................................................ 103
Table E.1 – Constrained Index assignment of data objects for IO-Link Safety ..................... 105
Table E.2 – Specific behavior of "Restore factory settings" ................................................. 106
Table E.3 – User actions to replace DefaultValues .............................................................. 108
Table E.4 – RecordItems of FSP_Protocol where allowed values shall be serialized ........... 109
Table E.5 – Sample serialization for FSP_ParamDescCRC ................................................. 109
Table F.1 – Description of PID file elements ....................................................................... 125
Table F.2 – Elements of a TPF ........................................................................................... 127
Table F.3 – Elements of the TBF......................................................................................... 132
Table F.4 – Invocation cases and behaviors ....................................................................... 134
Table F.5 – Communication Schema mapping .................................................................... 141
Table F.6 – Reaction on incorrect Tool behavior ................................................................. 142
Table F.7 – DTI conformance classes ................................................................................. 143
Table F.8 – DTI feature levels of Device Tools .................................................................... 143
Table F.9 – Interactions at conformance class combinations ............................................... 144
Table G.1 – Main scenarios of IO-Link Safety ..................................................................... 152
Table J.1 – Electric characteristic of Power2 ....................................................................... 156
1 0 Introduction
2 0.1 General
3 The base technology of IO-Link™ 1 is subject matter of the international standard IEC 61131-9
4 (see [2]). IEC 61131-9 is part of a series of standards on programmable controllers and the
5 associated peripherals and should be read in conjunction with the other parts of the series.
6 It specifies a single-drop digital communication interface technology for small sensors and
7 actuators – named SDCI, which extends the traditional switching input and output interfaces
8 as defined in IEC 61131-2 towards a point-to-point communication link using coded switching.
9 This technology enables the cyclic exchange of digital input and output process data between
10 a Master and its associated Devices (sensors, actuators, I/O terminals, etc.). The Master can
11 be part of a fieldbus communication system or any stand-alone processing unit. The
12 technology enables also the acyclic transfer of parameters to Devices and the propagation of
13 diagnosis information from the Devices to the upper-level automation system (controller, host)
14 via the Master.
15 Physical topology is point-to-point from each Device to the Master using 3 wires over
16 distances up to 20 m. The SDCI physical interface is backward compatible with the usual
17 24 V I/O signalling specified in IEC 61131-2. Transmission rates of 4,8 kbit/s, 38,4 kbit/s and
18 230,4 kbit/s are supported.
Product standards
ISO 12100
ISO 14119 IEC 60947-5-3 IEC 61496 IEC 61131-6 IEC 61800-5-2 General principles for design –
Interlocking Proximity Safety f. e.g. Safety for Safety functions Risk assessment and risk reduction
devices switches light curtains PLC for drives
Design of safety-related electrical, electronic and program-

IO-Link Security IEC 62443 mable electronic control systems (SRECS) for machinery
Guide Security
SIL based PL based

IEC 62453 IO-Link Installation Design objective
Communication server Guide
Applicable standards
IEC 61000-1-2 IEC 60204-1

Methods Safety of electri- ISO 13849
AIDA cal equipment Safety-related parts
Position of machinery
paper IO-Link Safety IEC 61000-6-7 (SRPCS)
Functional safety Generic EMC & FS
system and Non-electrical
communication IEC 61326-3-1 US: NFPA 79
ZVEI extensions EMC & FS (2006) Electrical
Position
paper
IEC 61784-3
Functional safety
communication
IEC 61131-9 IEC 62061
Single drop digital
communication interface Functional safety
IEC 61508 for machinery
for small sensors
Functional safety (SRECS)
and actuators (SDCI)
(FS)
Key (yellow) safety-related standards/documents (blue) fieldbus-related standards

(orange) IO-Link-related standard (dashed orange) this specification
19
20 Figure 1 – Relationship of this document to standards
21 The main advantages of the IO-Link technology are:
22 • international standard for dual use of either switching signals (DI/DO) or coded switching
23 communication respectively;
1 IO-Link TM is a trade name of the "IO-Link Community". This information is given for the convenience of users of
this specification and does not constitute an endorsement by the IO-Link Community of the trade name holder or
any of its products. Compliance to this standard does not require use of the registered logos for IO-Link TM . Use
of the registered logos for IO-Link TM requires permission of the "IO-Link Community".
24 • traditional switching sensors and actuators now providing alternatively single drop digital
25 communication within the same Device;
26 • one thin, robust, very flexible cable without shielding for power supply and signalling;
27 • lowest-cost digital communication down to the lowest end sensors and actuators.
28 As a consequence, the market demand for the extension of this technology towards functional
29 safety has been raised.
30 This document provides the necessary extensions to the basic IO-Link interface and system
31 standard for functional safety communication including compatibility to OSSDe based sensors
32 and the necessary configuration management. Figure 1 shows its relationships to internatio-
33 nal fieldbus and safety standards as well as to relevant specifications.
34 This document does not yet provide the necessary specifications for a functional safety
35 interface ("Combi") for actuators based on Port class B and for optional features such as func-
36 tional safety signal processing as required in [11]. This part has been postponed to a later
37 release.
38 The design objective for IO-Link Safety is up to SIL3 according to IEC 61508 and/or up to PLe
39 according to ISO 13849.
40 Parameterization within the domain of safety for machinery requires a "Dedicated Tool" per
41 FS-Device or FS-Device family. The Device Tool Interface (DTI) technology has been chosen
42 for the links between FS-Master Tool, FS-Device, and its "Dedicated Tool" (Device Tool).
43 The structure of this document is described in 4.9.
44 Conformity with this document cannot be claimed unless the requirements of Annex I are met.
45 Terms of general use are defined in IEC 61131-1 or in the IEC 60050 series. More specific
46 terms are defined in each part.
47 0.2 Patent declaration

48 The IO-Link Community draws attention to the fact that compliance with this document may
49 involve the use of patents concerning the functional safety point-to-point serial communication
50 interface for small sensors and actuators.
51 Attention is drawn to the possibility that some of the elements of this document may be the
52 subject of patent rights. The IO-Link Community shall not be held responsible for identifying
53 any or all such patent rights.
54 The IO-Link Community maintains on-line data bases of patents relevant to their standards.
55 Users are encouraged to consult the databases for the most up to date information
56 concerning patents.
57 IO-Link Safety –
58 Functional safety communication and system extensions –
59 based on IEC 61131-9 (SDCI)
60
61 1 Scope
62 For the design of functional safety communication on IO-Link there exist mainly three options:
63 • existing functional safety communication profiles (FSCP) specified within the IEC 61784-3-
64 x series, tunnelling across IO-Link;
65 • a new universal FSCP suitable for all fieldbuses standardized in IEC 61158, also tunnel-
66 ling across IO-Link;
67 • a new lean dedicated functional safety communication interface (IO-Link Safety) solely
68 between Device and Master requiring a safety gateway for the connection to FSCPs.
69 This document specifies only the new lean functional safety communication interface inclu-
70 ding connectivity of OSSDe type safety sensors (FS-Devices).
71 Figure 2 shows four typical fieldbus/FSCP configurations A to D with remote I/Os (RIO) and
72 attached FS-DIs as well as gateways to IO-Link Safety ("IOL-S"). The gateways contain
73 FSCP-specific FS-Masters. FS-Devices with OSSDe can be connected to FS-DIs or FS-
74 Masters. All IO-Link safety sensors (FS-Device) can communicate with any IO-Link Safety
75 Master (FS-Master) using the IO-Link Safety protocol regardless of the upper level FSCP-
76 system. The same is true for IO-Link safety actuators (FS-Devices) such as drives with
77 integrated safety. This means the largest component commonality for sensors and actuators
78 similar to the DI and DO interfaces standardized within IEC 61131-2.
FSCP A FSCP B
Ethernet-based Ethernet-based
"Classic" "Classic"
RIO FS-DI IOL-S RIO FS-DI IOL-S
 Local signal processing

 Largest commonality for
sensors and actuators
 Same FS-Device (OSSDe)
 Combi on Port Class B

RIO FS-DI IOL-S RIO FS-DI IOL-S
Ethernet-based "Classic"
Ethernet-based
FSCP C FSCP D
79
80 Figure 2 – IO-Link Safety on single platform
81 Safety sensors with OSSDe interfaces – equipped with IO-Link communication – can be
82 parameterized via auxiliary tools such as "USB-Masters", then connected to an FS-DI and
83 operated in OSSDe mode. They also can be operated in OSSDe mode on an FS-Master
84 supporting OSSDe. In case these safety sensors are equipped with IO-Link Safety
85 communication in addition, they can be operated in both modes, either OSSDe or IO-Link
86 Safety. This corresponds to the IO-Link SIO paradigm.
87 The concept of IO-Link Safety allows for local safety signal processing (safety functions) if the
88 FS-Master provides a local safety controller. This document specifies the interfaces if
89 required.
90 The IO-Link specifications [1] and [2] define a Master Port class B with an extra 24 V power
91 supply for actuators using a 5 pin M12 connector. The list of requirements in [11] suggests an
92 extension – called "Combi-Port" –, where the power-down of the extra power supply can be
93 controlled by the FS-Master itself. This document does not yet specify this kind of Master
94 Port class B. It is postponed until a later version.
95 NOTE The illustrations  to  be valid for all FSCPs.
96 This document does not cover communication interfaces or systems incorporating multi-point
97 or multi-drop linkages, or integration of IO-Link Safety into upper level systems such as
98 fieldbuses.
99 2 Normative references
100 The following documents, in whole or in part, are normatively referenced in this document and
101 are indispensable for its application. For dated references, only the edition cited applies. For
102 undated references, the latest edition of the referenced document (including any
103 amendments) applies.
104 IEC 60947-5-3, Low-voltage switchgear and controlgear – Part 5-3: Control circuit devices
105 and switching elements – Requirements for proximity devices with defined behaviour under
106 fault conditions (PDDB)
107 IEC 61000-1-2, Electromagnetic compatibility (EMC) - Part 1-2: General - Methodology for the
108 achievement of functional safety of electrical and electronic systems including equipment with
109 regard to electromagnetic phenomena
110 IEC 61000-6-7, Electromagnetic compatibility (EMC) - Part 6-7: Generic standards - Immunity
111 requirements for equipment intended to perform functions in a safety-related system
112 (functional safety) in industrial locations
113 IEC 61131-2, Programmable controllers – Part 2: Equipment requirements and tests
114 IEC 61131-9, Programmable controllers – Part 9: Single-drop digital communication interface
115 for small sensors and actuators (SDCI)
116 IEC 61496-1, Safety of machinery – Electro-sensitive protective equipment – Part 1: General
117 requirements and tests
118 IEC 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safety-

119 related systems - Part 2: Requirements for electrical/electronic/programmable electronic
120 safety-related systems
121 IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-

122 related systems - Part 3: Software requirements
123 IEC 61784-3:2016, Industrial communication networks - Profiles - Part 3: Functional safety
124 fieldbuses - General rules and profile definitions
125 IEC 62061, Safety of machinery – Functional safety of safety-related electrical, electronic and
126 programmable electronic control systems
127 IEC 62443 all, Security for industrial automation and control systems
128 IEC 62453, Field device tool (FDT) interface specification
129 ISO 12100:2010, Safety of machinery – General principles for design – Risk assessment and
130 risk reduction
131 ISO 13849-1:2015, Safety of machinery – Safety-related parts of control systems – Part 1:
132 General principles for design
133 ISO 14119:2013, Safety of machinery – Interlocking devices associated with guards –
134 Principles for design and selection
135 3 Terms, definitions, symbols, abbreviated terms and conventions

136 3.1 Common terms and definitions
137 For the purposes of this document, the terms and definitions given in IEC 61131-1 and IEC
138 61131-2, as well as the following apply.
139 3.1.1
140 address
141 part of the M-sequence control to reference data within data categories of a communication
142 channel
143 3.1.2
144 application layer
145 AL
146 <SDCI> 2 part of the protocol responsible for the transmission of Process Data objects and
147 On-request Data objects
148 3.1.3
149 block parameter
150 consistent parameter access via multiple Indices or Subindices
151 3.1.4
152 checksum
153 <SDCI> complementary part of the overall data integrity measures in the data link layer in
154 addition to the UART parity bit
155 3.1.5
156 CHKPDU
157 integrity protection data within an ISDU communication channel generated through XOR
158 processing the octets of a request or response
159 3.1.6
160 coded switching
161 SDCI communication, based on the standard binary signal levels of IEC 61131-2
162 3.1.7
163 COM1
164 SDCI communication mode with transmission rate of 4,8 kbit/s
165 3.1.8
166 COM2
168 3.1.9
169 COM3
171 3.1.10
172 COMx
173 one out of three possible SDCI communication modes COM1, COM2, or COM3
174 3.1.11
175 communication channel
176 logical connection between Master and Device
177 Note 1 to entry: Four communication channels are defined: process channel, page and ISDU channel (for
178 parameters), and diagnosis channel.
179 3.1.12
180 communication error
181 unexpected disturbance of the SDCI transmission protocol
2 Angle brackets indicate validity of the definition for the SDCI (IO-Link) technology
182 3.1.13
183 cycle time
184 time to transmit an M-sequence between a Master and its Device including the following idle
185 time
186 3.1.14
187 Device
188 single passive peer to a Master such as a sensor or actuator
189 Note 1 to entry: Uppercase "Device" is used for SDCI equipment, while lowercase "device" is used in a generic
190 manner.
191 3.1.15
192 Direct Parameters
193 directly (page) addressed parameters transferred acyclically via the page communication
194 channel without acknowledgement
195 3.1.16
196 dynamic parameter
197 part of a Device's parameter set defined by on-board user interfaces such as teach-in buttons
198 or control panels in addition to the static parameters
199 3.1.17
200 Event
201 instance of a change of conditions in a Device
202 Note 1 to entry: Uppercase "Event" is used for SDCI Events, while lowercase "event" is used in a generic manner.
203 Note 2 to entry: An Event is indicated via the Event flag within the Device's status cyclic information, then acyclic
204 transfer of Event data (typically diagnosis information) is conveyed through the diagnosis communication channel.
205 3.1.18
206 fallback
207 transition of a port from coded switching to switching signal mode
208 3.1.19
209 inspection level
210 degree of verification for the Device identity
211 3.1.20
212 interleave
213 segmented cyclic data exchange for Process Data with more than 2 octets through
214 subsequent cycles
215 3.1.21
216 ISDU
217 indexed service data unit used for acyclic acknowledged transmission of parameters that can
218 be segmented in a number of M-sequences
219 3.1.22
220 legacy (Device or Master)
221 Device or Master designed in accordance with [8]
222 3.1.23
223 M-sequence
224 sequence of two messages comprising a Master message and its subsequent Device
225 message
226 3.1.24
227 M-sequence control
228 first octet in a Master message indicating the read/write operation, the type of the
229 communication channel, and the address, for example offset or flow control
230 3.1.25
231 M-sequence error
232 unexpected or wrong message content, or no response
233 3.1.26
234 M-sequence type
235 one particular M-sequence format out of a set of specified M-sequence formats
236 3.1.27
237 Master
238 active peer connected through ports to one up to n Devices and which provides an interface
239 to the gateway to the upper level communication systems or PLCs
240 Note 1 to entry: Uppercase "Master" is used for SDCI equipment, while lowercase "master" is used in a generic
241 manner.
242 3.1.28
243 message
244 <SDCI> sequence of UART frames transferred either from a Master to its Device or vice versa
245 following the rules of the SDCI protocol
246 3.1.29
247 On-request Data
248 acyclically transmitted data upon request of the Master application consisting of parameters
249 or Event data
250 3.1.30
251 physical layer
252 first layer of the ISO-OSI reference model, which provides the mechanical, electrical,
253 functional and procedural means to activate, maintain, and de-activate physical connections
254 for bit transmission between data-link entities
255 Note 1 to entry: Physical layer also provides means for wake-up and fallback procedures.
256 [SOURCE: ISO/IEC 7498-1, 7.7.2, modified – text extracted from subclause, note added]
257 3.1.31
258 port
259 communication medium interface of the Master to one Device
260 3.1.32
261 port operating mode
262 state of a Master's port that can be either INACTIVE, DO, DI, FIXEDMODE, or SCANMODE
263 3.1.33
264 Process Data
265 input or output values from or to a discrete or continuous automation process cyclically
266 transferred with high priority and in a configured schedule automatically after start-up of a
267 Master
268 3.1.34
269 Process Data cycle
270 complete transfer of all Process Data from or to an individual Device that may comprise
271 several cycles in case of segmentation (interleave)
272 3.1.35
273 single parameter
274 independent parameter access via one single Index or Subindex
275 3.1.36
276 SIO
277 port operation mode in accordance with digital input and output defined in IEC 61131-2 that is
278 established after power-up or fallback or unsuccessful communication attempts
279 3.1.37
280 static parameter
281 part of a Device's parameter set to be saved in a Master for the case of replacement without
282 engineering tools
283 3.1.38
284 switching signal
285 binary signal from or to a Device when in SIO mode (as opposed to the "coded switching"
286 SDCI communication)
287 3.1.39
288 system management
289 SM
290 <SDCI> means to control and coordinate the internal communication layers and the
291 exceptions within the Master and its ports, and within each Device
292 3.1.40
293 UART frame
294 <SDCI> bit sequence starting with a start bit, followed by eight bits carrying a data octet,
295 followed by an even parity bit and ending with one stop bit
296 3.1.41
297 wake-up
298 procedure for causing a Device to change its mode from SIO to SDCI
299 3.1.42
300 wake-up request
301 WURQ
302 physical layer service used by the Master to initiate wake-up of a Device, and put it in a
303 receive ready state
304
305 3.2 IO-Link Safety: Additional terms and definitions

306 For the purposes of this document, the following additional terms and definitions apply.
307 3.2.1
308 error
309 discrepancy between a computed, observed or measured value or condition and the true,
310 specified or theoretically correct value or condition
311 Note 1 to entry: Errors may be due to design mistakes within hardware/software and/or corrupted information due
312 to electromagnetic interference and/or other effects.
313 Note 2 to entry: Errors do not necessarily result in a failure or a fault.
314 SOURCE: [IEC 61508-4:2010], [IEC 61158]
315 3.2.2
316 failure
317 termination of the ability of a functional unit to perform a required function or operation of a
318 functional unit in any way other than as required
319 Note 1 to entry: The definition in IEC 61508-4 is the same, with additional notes.
320 Note 2 to entry: Failure may be due to an error (for example, problem with hardware/software design or message
321 disruption)
322 SOURCE: [IEC 61508-4:2010, modified], [ISO/IEC 2382-14.01.11, modified]
323 3.2.3
324 fault
325 abnormal condition that may cause a reduction in, or loss of, the capability of a functional unit
326 to perform a required function
327 Note 1 to entry: IEV 191-05-01 defines “fault” as a state characterized by the inability to perform a required
328 function, excluding the inability during preventive maintenance or other planned actions, or due
329 to lack of external resources.
330 SOURCE: [IEC 61508-4:2010, modified], [ISO/IEC 2382-14.01.10, modified]

331 3.2.4
332 FS-Device
333 single passive peer such as a functional safety sensor or actuator to a Master with functional
334 safety capabilities
335 3.2.5
336 FS-Master
337 active peer with functional safety capabilities connected through ports to one up to n Devices
338 or FS-Devices and which provides an interface to the gateway to the upper level
339 communication systems (NSR or SR) or controllers with functional safety capabilities
340 3.2.6
341 FSP parameter
342 parameter set for the administration and operation of the IO-Link Safety protocol
343 3.2.7
344 FST parameter
345 parameter set for the safety-related technology of an FS-Device, for example light curtain
346 3.2.8
347 Safety Protocol Data Unit
348 SPDU
349 protocol data unit transferred through the safety communication channel
350 [SOURCE: IEC 61784-3:2015 modified]
351
352 3.3 Symbols and abbreviated terms

AIDA Automatisierungsinitiative Deutscher Automobilhersteller
AL application layer
BEP bit error probability
C/Q connection for communication (C) or switching (Q) signal (SIO)
CRC cyclic redundancy check
DDO Device data object
DI digital input
DL data link layer
DO digital output
DTI Device Tool Interface
FDI Field Device Integration [IEC 62769]
FDT Field Device Tool [IEC 62453]
FS functional safety
FSCP functional safety communication profile (for example IEC 61784-3-x series)
FS-AI functional safety analog input
FS-DI functional safety digital input
I/O input / output
IODD IO Device Description
IOPD IO-Link Parameterization & Diagnostic tool
IOL-S IO-Link Safety
L- power supply (-)
L+ power supply (+)
N24 24 V extra power supply (-); Port class B
NSR non safety-related
OD On-request Data
OK "OK", values or state correct

OSSD output signal switching device (self-testing electronic device with built-in OSSD) [IEC 61496-1]
OSSDe output signal switching device (self-testing electronic device with built-in OSSD) [This document]
OSSD1/2e pin assigment of both OSSDe signals according to [14]
OSSDm output signal switching device (relay and solid state outputs) [IEC 60947-5-5]
P24 24 V extra power supply (+); Port class B
PD Process Data
PDin functional safety input process data (from an FS-Master's view)
PDout functional safety output process data (from an FS-Master's view)
PDCT port and Device configuration tool
PFH (average) probability of a dangerous failure per hour
PID program interface description
PL physical layer
PLC programmable logic controller
PS power supply (measured in V)
RIO remote I/O
SCL safety communication layer
SDCI single-drop digital communication interface [IEC 61131-9]
SIO standard input output (digital switching mode) [IEC 61131-2]
SM system management
SPDU safety protocol data unit
SR safety-related
SSI synchronous serial interface (usually for encoders)
TAF temporary acknowledgment file
TBF temporary backchannel file
TPF temporary parameter file
UART universal asynchronous receiver transmitter
UML 2 unified modeling language, edition 2 [ISO/IEC 19505-2]
WURQ wake-up request pulse
XML extensible markup language
353
354 3.4 Conventions
355 3.4.1 Behavioral descriptions
356 For the behavioral descriptions, the notations of UML 2 are used, mainly for state and
357 sequence diagrams (see [3], [6], or [7]).
358 Events to trigger a transition usually can be a signal, service call, or timeout. Logic conditions
359 (true/false) shall be the result of a [guard]. To alleviate the readability and the maintenance of
360 the state machines, the diagrams do not provide the actions associated with a transition.
361 These actions are listed within a separate state-transition table according to IEC 62390 [8].
362 The state diagrams shown in this document are entirely abstract descriptions. They do not
363 represent a complete specification for implementation.
364 3.4.2 Memory and transmission octet order

365 Figure 3 demonstrates the order that shall be used when transferring WORD based data types
366 from memory to transmission and vice versa.
367 NOTE Existing microcontrollers can differ in the way WORD based data types are stored in memory: "big endian"
368 and "little endian". If designs are not taking into account this fact, octets can be erroneously permuted for
369 transmission.
"Big endian" Depending on the architecture

"Little endian"
of the microcontroller in use
n+1 LSO MSO n+1 Memory

Memory
addresses addresses
n MSO LSO n
Transmission MSO LSO
0 t
Transmission time
370
371 Figure 3 – Memory and transmission octet order
372 4 Overview of IO-Link Safety

373 4.1 Purpose of the technology and feature levels
374 4.1.1 Base IO-Link Safety technology
375 This document specifies a new lean functional safety communication protocol on top of the
376 existing IO-Link transmission system specified in [1] or within the international standard IEC
377 61131-9 [2]. Figure 4 illustrates how the corresponding IO-Link Safety communication layers
378 are located within the architectural models of Master and Device such that they become FS-
379 Master and FS-Device. Most of the original IO-Link design remains unchanged for this
380 specification.
To upper level safety system
FS-Device Application FS-Master Application

IO-Link Safety IO-Link Safety
Communication Layer Communication Layer (FS-Master) Tool:
- configuration,
- parameterization,
IO-Link IO-Link - diagnosis,
FS-Device FS-Master - identification &
maintenance
IO-Link + IO-Link Safety data transmission

381
382 Figure 4 – IO-Link Safety communication layer model
383 The IO-Link Safety communication layer accommodates the functional safe transmission
384 protocol. This protocol generates a safety PDU consisting of the FS-I/O data, protocol control
385 or status data, and a CRC signature. The safety PDU together with optionally non-safety-
386 related data is transmitted as IO-Link Process Data between an FS-Master and one single FS-
387 Device (point-to-point).
388 IO-Link Safety increases the number of Port modes and thus requires changes to the Physical
389 Layer and System Management.
390 Changes are required for the Master-(Software)-Tool to provide the necessary safety-related
391 configuration and parameterization of the protocol (FSP-Parameter) as well as of the
392 particular FS-Device technology (FST-Parameter).
393 IO-Link Safety comprises not only the digital communication; it also supports OSSDe (class A)
394 in this version, similar to the SIO mode.
395 IO-Link Safety does not support
396 • wireless connections between FS-Master and FS-Device (see Annex H.2);
397 • cascaded FS-Master/FS-Device systems.
398 4.1.2 From "analog" and "switching" to communication

399 In "Safety-for-Machinery", usually the switch states (on/off) of relays or sensors are
400 transmitted similar to standard IO-Link (SIO) as a 24 V or 0 V signal to FS-DI-Modules within
401 remote I/Os. In contrast to standard IO-Link, due to safety requirements, these signals are
402 redundant, either equivalent (OSSDe = 1100) or antivalent (OSSDm = 0110) switching.
403 NOTE OSSDe stands for IEC 61496-1 and OSSDm for IEC 60947-5-5 concepts.
404 The electrical characteristics for the OSSDe interface are following IEC 61131-2, type 1 (see
405 Figure 5).
"Single-platform":
IOL-OSSD Pin Signal Definition Standard
1 L+ 24 V IEC 61131-2
IOL-OSSDe
L+ 2 I/Q Not connected, IEC 61131-2
DI / IOL-OSSD2e, or DO
IOL-OSSD 3 L- 0V IEC 61131-2

1 C/Q
2 4 4 Q DI / IOL-OSSD1e, or DO IEC 61131-2
I/Q 3 COMx 4,8 / 38,4 / 230,4 kbit/s C "Coded switching" COM1…3 IEC 61131-9
+ new IOL-Safety profile + "Upgrade"
+ "Profile"
L-
Key: IOL-OSSDe = Equivalent switching redundant signals

406
407 Figure 5 – Port interface extensions for IO-Link Safety
408 Measurement of physical quantities such as temperature, pressure, position, or strain (FS-AI-
409 Modules) has several interface solutions such as 4 to 20 mA, 0 to 10 V, or SSI, but no
410 common signal transmission technology (see Figure 6, left).
411 Actuators such as motors can be de-energized via FS-DO-Modules and connected relays as
412 shown in Figure 6 (left).
Fieldbus
FS-AI FS-DI FS-DO FS-Master

Remote I/O
0 0 0 0 0 0
7 7 7 7 7 7
e.g. 0 …10 V OSSD PM IO-Link Safety
Measurement: Electro-mechanics: Electro-mechanics: Measurement: Sensors: Actuators:

- Temperature, - E-Stop, - Relays - Temperature, - E-Stop (self-testing) - Drives
- Pressure, - Two hands control - etc. - Pressure, - Light curtains - Switch gear
- Length, - Floor mat - Length, - etc. - Valves
- Strain, - etc. - Strain,
… …
413
414 Figure 6 – Migration to IO-Link Safety
415 Without additional interfaces, it was not possible in all cases to configure or parameterize the
416 safety devices or to receive diagnosis information.
417 IO-Link Safety can now provide a functional safe and reliable solution for process data
418 exchange (signal states and measurement values) via single drop digital communication
419 (SDCI), as well as parameterization and diagnosis (see Figure 6, right).
420 4.1.3 Minimized paradigm shift from FS-DI to FS-Master

421 Similar to nowadays safety devices for FS-DI modules (see Figure 7) and in contrast to
422 FSCP-based safety devices, it is not necessary to
423 setup an authenticity code switch or adequate software solution;

424 assign a watchdog time;
425 use any software tool in case of FS-Device replacement.
426 Authenticity is guaranteed through checking of the correct FS-Device to the assigned FS-
427 Master Port during commissioning similar to FS-DI modules. However, IO-Link Safety
428 provides means to discover any incorrect plugging.
429 IO-Link Safety uses a watchdog timer for the transmission of safety data in time (Timeliness).
430 The system is able to calculate the required watchdog time automatically due to the point-to-
431 point nature of the transmission.
432 FS-Device replacement without tools can be achieved using the original IO-Link Data Storage
433 mechanism.
FS-DI FS-Master
• No authenticity code switches

0 0
• No watchdog time assignments

7 7
Redundant
signals (OSSD) IO-Link Safety • No tool @ FS-Device replacement
• Port selective passivation in case of a port fault
Safety sensor FS-Device • IO-Link cable: 20 m, flexible, no shielding
434
435 Figure 7 – Minimized paradigm shift from FS-DI to FS-Master
436 The FS-Master supports port selective passivation in case of a port fault and signal granular
437 passivation in case of a channel fault within for example a remote I/O terminal ("Hub")
438 connected to an FS-Master Port.
439 Cables are the same as with IO-Link, i.e. unshielded with a maximum of 20 m. However, due
440 to the higher permitted power supply current of 1000 mA per Port, the overall loop resistance
441 RL eff can only be 1,2 Ohm (see Table 9).
442 NOTE Compliance to AIDA rules requires cable color to be any except yellow. However, the connector color shall
443 be yellow (RAL 1004).
444
445 4.1.4 Following the IO-Link paradigm (SIO vs. OSSDe)

446 Standard IO-Link supports a port type A (4 pin) without extra power supply and a port type B
447 (5 pin) with extra 24 V power supply (see [1] or [2]). IO-Link Safety takes care of several
448 specification levels "a" to "d" (see Figure 8). The number of pins refers to the possible FS-
449 Master pins.
Feature levels
IO-Link class B paradigm stage Level d:

Extra 24 V power
(5 pins)
IO-Link SIO paradigm stage Level c:

OSSDe supported
(4 pins with 5th pin as hole in M12)
Level b:
OSSDe tolerated
(4 pins with 5th pin as hole in M12)
Level a:
Safety communication only
(maximum of 3 pins; open wires) FS-Master types
450
451 Figure 8 – FS-Master types and feature levels
452 The original pin layouts of IO-Link for port class A are shown in Figure 9 together with the
453 extensions for level "a" through "c". Table 1 shows the details of these levels.
FS-Device FS-Master
L+ (24 V / < 1000 mA) L+ (24 V / > 1000 mA)
1 Q/OSSD1/C Q/C/FS-DI1 + 1
OSSD 2 + IOLsafety IOLsafety NC/DI/FS-DI2
2 4 4 5 2
3 3
L- (0 V / < 1000 mA) Type C (class 1): L- (0 V / > 1000 mA)

test pulse length < 1 ms
Test pulses Test pulses Wake-up pulse
OSSD 1 OSSD 1
OSSD 2 OSSD 2
Possible operations:
- SIO
- OSSDe
- IO-Link
- IO-Link + IOLsafety
454
455 Figure 9 – Original pin layout of IO-Link (port class A)
456 Level "a" provides communication only (Pin 1, 3, and 4). That means support for sensor-type
457 FS-Devices and actuator-type FS-Devices.
458 Due to the redundant nature of most of the safety device interfaces, IO-Link Safety considers
459 pin 2 for the redundant signal path (e.g. OSSD2e) besides pin 4 for the primary signal path
3
460 (e.g. OSSD1e) . Thus, level "b" allows FS-Devices to provide OSSDe outputs besides the IO-
461 Link Safety communication capability. They can be parameterized with the help of a "USB-
462 Master" and be connected to any FS-DI module in switching mode. When connected to an FS-
463 Master, safety and standard non-safety communication is possible.
464 Level "c" corresponds to the SIO level of standard IO-Link Master. In this case, the FS-Master
465 supports an OSSDe mode besides communication (Pin 1, 3, 4 and 2).
3 FS-Devices are based on electronics and not on relays. Thus, the electronic version OSSDe is considered.
466 Table 1 shows the pin layout and possible operational modes for the feature levels "a" to "c"
467 of the port class A FS-Device and FS-Master.
468 Table 1 – Operational modes of feature level "a" to "c" (port class A)
Feature FS-Device FS-Master

level
Pin 2 Pin 4 Pin 2 Pin 4
"a" - NC, DI, DO - DI, DO - NC, DI, DO - DI, DO
- IO-Link - IO-Link
- IO-Link + IOL-S - IO-Link + IOL-S
"b" - NC, DI, DO - DI, DO - NC, DI, DO - DI, DO
- OSSD2e - OSSD1e - IO-Link
- IO-Link - IO-Link + IOL-S
- IO-Link + IOL-S
"c" - NC, DI, DO - DI, DO - NC, DI, DO - DI, DO
- OSSD2e - OSSD1e - FS-DI - FS-DI
- IO-Link - IO-Link
- IO-Link + IOL-S - IO-Link + IOL-S
Key IOL-S = IO-Link Safety
469
470 Figure 10 shows the optimized OSSDe commissioning with FS-Masters:
471 • No filter adjustments due to fixed maximum test pulse length of 1 ms according to type C
472 and class 1 in [12], and
473 • No discrepancy time adjustments due to fixed maximum discrepancy.
FS-DI FS-Master
0 0 • No filter adjustments
7 7 • No discrepancy time adjustments

Redundant signals
(OSSDe)
• Port selective passivation in case of a port fault
• IO-Link cable: 20 m, flexible, no shielding
Safety sensor FS-Device

474
475 Figure 10 – Optimized OSSDe commissioning with FS-Master
476 4.1.5 Port class B (Classic and Combi)

477 The original strategy for a port class B provides for an extra 24 V power supply for actuators
478 supplementing the main 24 V power supply of IO-Link (see [1]). This extra power supply was
479 already considered in external functional safety concepts. According to these concepts, it is
480 possible to switch off the extra power supply via FSCP controls and thus de-energize the
481 actuator [11]. Annex Jspecifies details for this "classic" approach.
482 The new strategy suggests incorporating the P24- and N24-safety switches into the FS-
483 Master port and controlling them via signals within the FSCP message or by local safety
484 controls. The required technology corresponds to level "d" in Figure 8.
485 It is intended to specify the additional port electronics and control features in a later version of
486 this document.
487 Figure 11 shows the pin layout, signal, and power supply assignment as well as the internal
488 switches for L+, P24, and N24.
FS-Device FS-Master
L+ (24 V) L+ (24 V)
Power switch control
1 Q/C/FS-DI1 + 1
IOLsafety NC/DI/FS-DI2
2 5 4 4 5 2
P24
3 3
N24
L- (0 V) L- (0 V)
489
490 Figure 11 – Level "d" of an FS-Master (Combi – class B)
491 4.1.6 "USB-Master" with safety parameterization

492 It is possible to use upgraded "USB-Masters" for off-site configuration, parameterization and
493 test as shown in Figure 12. Due to functional safety requirements, it will be necessary to
494 extend the Master-Tool software for the functional safe configuration and parameterization of
495 the FS-Device technology (FST-Parameters).
Off-site configuration & parameterization
Fieldbus FS-DI Modul

FS-Master
"USB Master"
Tool software
with safety
0 0 0 0
Remote IO 7 7 7 7 USB
OSSDe "USB.Master"
Parameter Test
FS-Device FS-Device
496
497 Figure 12 – Off-site configuration and parameterization
498 Table 2 shows the device types that can be supported by such a "USB-Master".
499 4.1.7 Interoperability matrix of safety devices

500 Table 2 provides an overview of typical safety sensors and actuators and their interoperability
501 with FS-Masters of different feature levels, a "USB-Master" upgraded to safety parameteri-
502 zation, and conventional FS-DI modules connected to FSCPs.
503 Table 2 – Interoperability matrix of safety devices
Device type FS-Master "USB- FS-DI

Master" module
Communi- OSSDe OSSDe with safety (FSCP)
cation tolerated supported parameteri-
"a" "b" "c" zation
Sensor with OSSDe a - - OSSDe - OSSDe
Sensor with OSSDe and IO-Link - - OSSDe IO-Link b OSSDe
Sensor with OSSDe and IOL-S IOL-S IOL-S OSSDe or IO-Link OSSDe
IOL-S
Sensor with IOL-S communication only, IOL-S IOL-S IOL-S IO-Link -
e.g. light curtain
Sensor with OSSDm, e.g. E-Stop - - - - OSSDm
Device type FS-Master "USB- FS-DI

Master" module
Communi- OSSDe OSSDe with safety (FSCP)
cation tolerated supported parameteri-
"a" "b" "c" zation
Actuator with IOL-S, e.g. 400 V power IOL-S IOL-S IOL-S IO-Link -
drive, low voltage switch gear
Key IOL-S = IO-Link Safety including non-safety USB = Universal Serial Bus, currently the most common
a Pin layout according to [14]. interface amongst possible others for offsite
parameterization tools due to fast communication
b Pin layout may differ combined with power supply
504
505 4.2 Positioning within the automation hierarchy

506 Figure 13 shows the positioning of IO-Link Safety within the automation hierarchy.
Combined NSR PLC / FS-PLC / Host / FS-Host

Key
and SR technology Parameter
Fieldbus controller server
Fieldbus
integration
Fieldbus interface Engineering:

Controller: - configuration,
e.g. PC or drive - parameterization,
Gateway application
- diagnosis,
- identification &
FS-Master maintenance
IO-Link
/SDCI Port 1 Port 2 Port n Data
with storage
IO-Link
Safety
Device FS-Device FS-Device
Application FS-Terminal Application

Device Dedicated tool
Device description Device
description description
Switching devices
507
508 Figure 13 – IO-Link Safety within the automation hierarchy
509 Classic safety is relay based and thus seemed to be straightforward, easily manageable, and
510 reliable. However, the same criteria that led to the success of fieldbuses, led to the success of
511 functional safety communication profiles (FSCP) on top of the fieldbuses also: reduced wiring,
512 variable parameterization, detailed diagnosis, and more flexibility. IO-Link is the perfect
513 complement to the fieldbus communication and bridges the gap to the lowest cost sensors
514 and actuators. It not only provides communication, but power supply on the same flexible and
515 unshielded cable. One type of sensor can be used in the traditional switching mode or in the
516 coded switching mode (communication). IO-Link Safety follows exactly this paradigm.
517 It aims for two main application areas. One is building up safety functions across the IO-Link
518 Safety communications and the functional safety communications across fieldbuses. The
519 other builds up safety functions "locally" between a safety controller and safety
520 sensors/actuators using IO-Link Safety communication.
521 IO-Link Safety allows for building up power saving FS-Devices ("green-line"), for self-testing
522 safety sensors in order to avoid yearly testing, for the reduction of interface types (e.g. 0 to
523 10 V, 4 to 20 mA, etc.), and for robust and reliable transmission of safety information.
524 Last but not least it is a precondition for new automation concepts such as Industry 4.0 or the
525 Internet-of-Things (IoT).
526 4.3 Wiring, connectors, and power supply

527 Port class A types (3 to 4 wires): Cables and connectors as specified in [1] for Class A can be
528 used for IO-Link Safety also. However, due to the higher permitted power supply current of up
529 to 1000 mA per Port, the overall loop resistance RL eff can only be 1,2 Ohm. No shielding is
530 required.
531 Port class B types (5 wires): Cable, wire gauges, shielding, maximum switched currents,
532 interference, signal levels, etc. are not specified within this document.
533 4.4 Relationship to IO-Link

534 The IO-Link communication and its SIO mode are used as the base vehicle ("black channel")
535 for IO-Link Safety. Besides IO-Link Safety, any FS-Master Port can be configured for standard
536 IO-Link operation also.
537 The independent signal inputs of the SIO mode on Pin 2 and Pin 4 are scanned by an FS-
538 Master simultaneously to achieve an OSSDe interface. The result is propagated to the upper
539 level safety system as one safety signal. A new Safety Layer Manager supports this feature.
540 Another new Port configuration mode enables the IO-Link Safety communication. Standard
541 state machines are slightly extended to support
542 • detection of a Ready pulse from the FS-Device on Pin 4

543 • power supply (Pin 1) switching OFF/ON in case an FS-Device missed the Wake-up
544 sequence and started its OSSDe operation
545 • transmission of functional safety protocol parameters (FSP) during PREOPERATE from
546 FS-Master to the FS-Device
547 • activation of the IO-Link safety communication layer (SCL)
548 • activation of the FS Process Data Exchange within the Safety Layer Manager
549
550 4.5 Communication features and interfaces

551 FS Process Data from and to an FS-Device are always packed into a safety code envelop
552 consisting of a safety PDU counter, protocol Control/Status information, and a 16/32 bit CRC
553 signature. The minimum safety PDU size is 3 octets in case of no FS Process Data. IO-Link
554 Safety uses M-Sequence TYPE_2_V.
555 Only a subset of the IO-Link data types is permitted: Boolean (packed as record),
556 IntegerT(16), and IntegerT(32).
557 Parameterization within the domain of safety for machinery requires a "Dedicated Tool" per
558 FS-Device or FS-Device family. The Device Tool Interface (DTI) based on proven technology
559 has been chosen for the links between FS-Master Tool, FS-Device, and its "Dedicated Tool".
560 The FS-Master Tool shall provide communication means for a "Dedicated Tool" to allow for
561 the transmission of safety technology parameters (FST parameters) to and from an FS-
562 Device. The "Dedicated Tool" and the FS-Device are both responsible for sufficient means to
563 secure the transmitted data, for example via CRC signature or read-back.
564 4.6 Parameterization

565 IO-Link Safety comprises a three-tier concept. The first tier is IODD based and contains all
566 basic non-safety parameters for a Device or FS-Device.
567 The second tier requires an extension of the IODD for the fixed set of protocol parameters
568 (FSP). These parameters are safety-related and secured via CRC signature against
569 unintended changes of the IODD file. The interpreter of the FS-Master Tool provides a safety-
570 related extension for the handling of the FSP parameters. Usually, the FS-Master Tool is able
571 to determine and suggest the FSP parameter assignments (instance values) automatically
572 and thus relieves the user from assigning these values initially. He can check the plausibility
573 of the values and modify them if required.
574 The third tier deals with technology specific safety parameters (FST) of an FS-Device. IO-Link
575 Safety classifies two types of FS-Devices. Type "basic" requires only a few orthogonal FST
576 parameters, whereas type "complex" can have a number of FST parameters requiring
577 business rules and verification or validation wizards. Usually, the latter comes already with
578 existing PC software ("Dedicated Tool") used for several functional safety communication
579 profiles for fieldbuses.
580 The FST parameters for type "basic" are coded as any non-safety parameter within the IODD.
581 They can be modified and downloaded to the FS-Device as usual. However, a diverse second
582 path allows for checking these assignments for correctness. At the end of a parameterization
583 session, the user launches a safety-related "Dedicated Tool" (FS-IOPD) for the calculation of
584 a CRC signature across all FST instance values provided by the FS-Master Tool.
585 For both types of FS-Devices, the "Dedicated Tool" presents a CRC signature, which the user
586 can copy into one of the FSP parameters. Upon reception of the FSP parameters at start-up,
587 the FS-Device calculates a CRC signature across the locally stored instance values and
588 compares it with the received CRC signature.
589 This method is used also for the check after using the IO-Link Data Storage mechanism.
590 4.7 Role of FS-Master and FS-Gateway

591 The role of the FS-Master is extended to safe monitoring of Process Data, transferred to and
592 from FS-Devices with respect to timeliness, authenticity, and data integrity according to IEC
593 61784-3. Concerning authenticity, it uses the authenticity code assigned to the FS-Master by
594 the upper level FSCP system and the port number. This prevents from local port related mis-
595 connections and misconnections whenever several FS-Masters are located side by side.
596 An FS-Master can be equipped by a safety controller, for example according to IEC 61131-6,
597 or vice versa, and thus build-up a stand-alone safety system with its own complete safety
598 functions.
599 With the help of an FS-Gateway in conjunction with the FS-Master, safety functions can be
600 build-up across the upper level FSCP system using the safety sensors and actuators
601 connected to the FS-Master.
602 4.8 Mapping to upper level systems

603 Specification of the mapping to an upper level FSCP system is the responsibility of the
604 particular fieldbus organization. IO-Link Safety made provisions to meet the majority of
605 FSCPs for example via reduced number of data types, descriptions of safety IO data, port
606 selective passivation, and operator acknowledgment signals to prevent from automatic restart
607 of machines.
608 4.9 Structure of the document

609 The structure of this document complies mostly with the structure of [1]. Clause 5 specifies
610 the extensions to the Physical Layer (PL), mainly the OSSDe issues, the wake-up behavior,
611 and the additional Port modes. Extensions to SIO are specified in clause 6, those to data link
612 layer (DL) in clause 7, those to system management (SM) in clause 8, those to the FS-Device
613 in clause 9, and those to the FS-Master in clause 10.
614 The core part of this document is the safety communication layer (SCL) in clause 11. It
615 comprises the SCL services, protocol, state machines, and management. In addition it deals
616 with integrity measures, with protocol (FSP) and technology (FST) parameters, with the
617 integration of "Dedicated Tools" via Tool Calling Interface technology, with port selective
618 passivation, and with SCL diagnosis. Clause 12 complements the core part by functional
619 safety processing either through mapping to the upper level system or local.
620 Extensions to parameters and commands are specified in Annex A, those to EventCodes in
621 Annex B, and those to data types in Annex C. CRC polynomial issues are presented in
622 Annex D, the IODD aspects in Annex E, the Device Tool Interface technology in Annex F,
623 main scenarios in Annex G, and the system requirements in Annex H. Assessment issues are
624 described in Annex I. Annex J specifies in more detail the "classic" port B and Annex K test
625 issues.
626 5 Extensions to the Physical Layer (PL)

627 5.1 Overview
628 Figure 14 shows the adapted physical layer of an FS-Master (class A).
System Management Data Link Layer
Master Pin 4 Pin 2

Port x handler DL-mode handler Message handler
OSSDe OSSDe
DI DI
PL-SetMode.req PL-Ready.ind PL-WakeUp.req PL-Transfer.req PL-Transfer.ind
Mode switch
Inactive Ready/Wake-up Coded switching Switching signal Option

Physical Layer (port)
Medium
629
630 Figure 14 – The IO-Link physical layer of an FS-Master (class A)
631 Pin 2 and 4 shall be scanned simultaneously to achieve OSSDe functionality. The FS-Master
632 shall scan the C/Q line for the Ready signal of the FS-Device.
633 Figure 15 shows the adapted physical layer of an FS-Device (class A).
System Management Data Link Layer
Device
Line handler DL-mode handler Message handler
Pin 4 Pin 2
OSSDe OSSDe
PL-SetMode.req PL-Ready.req PL-WakeUp.ind PL-Transfer.ind PL-Transfer.req
Mode switch
Ready/Wake-up Coded switching Switching signal Option
Physical Layer
Medium
634
635 Figure 15 – The IO-Link physical layer of an FS-Device (class A)
636 Pin 2 and 4 carry the OSSDe signals. The FS-Device shall set the Ready signal after internal
637 safety testing.
638 5.2 Extensions to PL services

639 5.2.1 PL_SetMode
640 The PL-SetMode service is extended by the additional TargetMode "OSSDe" (C/Q line and I/Q
641 line in digital input mode).
642 5.2.2 PL_Ready

643 The PL-Ready service initiates or indicates a Ready signal on the C/Q line. Whenever the FS-
644 Device finished its internal safety-related hardware and software tests, it sets this signal. The
645 FS-Master polls this signal and upon reception initiates the wake-up sequence. This
646 unconfirmed service has no parameters. The service primitives are listed in Table 3.
647 Table 3 – PL_Ready
Parameter name .req .ind
<none>
648
649 5.3 Transmitter/receiver

650 5.3.1 Assumptions for the expansion to OSSDe
651 Figure 16 shows the cross compatibility between OSSD based safety sensors and OSSDe
652 based FS-Devices.
Safety DI-Module FS-Master
0 0
7 7
Not OSSDe
specified (L ≤ 20 m)
Type C, OSSDe
class 1 (L *) )
(L *) )
Safety sensor FS-Device

(OSSD according IEC 61496-1) (OSSDe according to this specification)
Key *) length is manufacturer specific

653
654 Figure 16 – Cross compatibility OSSD and OSSDe
655 The following assumptions are the basis for the design of the OSSDe expansion:
656 • The SIO paradigm of IO-Link shall apply for IO-Link Safety in order to allow manufacturers
657 the combined function of OSSDe and IO-Link Safety communication within one FS-Device.
658 • A Port on the FS-Master (with "FS-DI" according to Figure 9) shall have fixed
659 configurations as either IO-Link Safety or OSSDe interface with no or minor adjustments in
660 respect to addressing, watchdog times, discrepancy times, or filter times.
661 • In order to allow OSSD based sensors on the market to be connected to the FS-Master,
662 the FS-DI interface shall support the necessary adjustments for Type "C", class "1"
663 devices according to [12].
664 • The OSSDe interface shall only be designed as input for the FS-Master port (safety
665 sensors, Class A connectors). Most actuators are supplied by three-phase alternating
666 current such as power drives, low voltage switch gears, motor starters, etc.
667 • Actuators such as valves with diversity and relays shall be supported by FS-Master with
668 Ports "level d" (see clause 6).
669 5.3.2 OSSDe specifics
670 5.3.2.1 General
671 Similar to the SIO approach, FS-Master according to level "c" support connectivity to existing
672 functional safety devices with OSSDe. OSSDe in this document is defined as two outputs with
673 signals that are both switching in equivalent manner as opposed to antivalent manner, where
674 one signal is normally off and the other normally on (OSSDm).
675 The FS-Master port is designed to achieve a maximum of possible compatibility to existing
676 OSSD devices using interface type C, class 1 defined in [12].
677 Figure 17 shows a corresponding reference model from [12], adapted to IO-Link Safety. The
678 information-"source" on the left corresponds for example to a sensor device, whereas the
679 information-"sink" on the right side represents an input of the FS-Master Port class A. Power
680 is supplied by the sink.
+
+
OSSD1
TG1
TE1 Ri Ci Li
FS-Device FS-Master
OSSD2
TG2
TE2 Ri Ci Li
GND
Keys
TG Test pulse generation FS-Device = Information source
TE Test pulse evaluation FS-Master = Information sink
681
682 Figure 17 – Principle OSSDe function
683 The worst case values for the line resistance and capacitance are defined in Table 9. In case
684 of IO-Link Safety, line inductance is negligible at a length of 20 m. The design of the FS-
685 Master Port shall ensure values for R i , C i , and L i guaranteeing proper signal behavior
686 according to Table 8.
687 Table 4 shows the OSSD states and conditions defined in IEC 61496-1:2012.
688 Table 4 – OSSD states and conditions
State Cause Voltage range Current
OFF Demand - 3 V to + 2 V r.m.s < 2 mA (leakage)

(+ 5 V peak) NOTE
ON No demand + 11 V to + 30 V > 6 mA
NOTE IEC 61131-9 permits 5 mA for the voltage range of 5 V to 15 V
689
690 OFF state:
691 For this interface, the OFF state is defined as the "powerless" state, where voltage and
692 current of at least one OSSDe shall be within (voltage) and below (current) defined limits (see
693 Table 4). If the safety function is demanded, or the source (the device) detects a fault, the
694 OSSDe signals shall go to the OFF state. Antivalent voltage levels, so-called discrepancy, on
695 both OSSDe outputs of the device shall be treated as OFF state. The duration of this state
696 shall be within a specified discrepancy tolerance time. If the tolerance time is exceeded the
697 port is considered to be faulty.
698 ON state:
699 For this interface, the ON state is defined as the "powered" state, where voltage and current
700 on both OSSDe outputs shall be within the voltage range and above defined current limits,
701 when sinked by IEC 61131-2 inputs (see Table 4). Test pulses within specified ranges in
702 voltage levels, durations and intervals are permitted. Antivalent voltage levels, so-called
703 discrepancy, on both OSSDe outputs of the device shall be treated as OFF state.
704 5.3.2.2 Detection of cross connection faults

705 Tests are required for the detection of the cross connection faults specified in IEC 61496-1
706 and shown in Table 5.
707 Table 5 – Cross connection faults
Fault Diagnostics
Short circuit between OSSD 1 and OSSD 2 Test pulses (runtime diagnosis)
Fault Diagnostics
Short circuit between OSSD 1 or OSSD 2 and V+ Test pulses (runtime diagnosis)
Short circuit between OSSD 1 or OSSD 2 and V- Test pulses (runtime diagnosis)
Open circuit of the power supply return cable (V-) Type test, maximum leakage current
Open circuit of the functional earth (bonding) conductor Type test, no functional earth
Open circuit of the screen of screened cable Not required due to no shielding
Incorrect wiring Discrete wiring only, organizational issue (test
during commissioning)
708 The means for detecting short circuits are test pulses at runtime. The means for testing the
709 behavior in case of open circuits is the type test during the assessment. Figure 18 shows the
710 test pulses approach for the detection of cross connection faults.
Duration
OSSD 1 Period
OSSD 2
Check:
Cross fault
711
712 Figure 18 – Test pulses to detect cross connection faults
713 Three methods of testing (intervals) are commonly used:
714 • Test pulses at each program cycle of the safety device (dependency on configuration)
715 • Test pulses at fixed times
716 • Test pulses after any commutation OFF  ON
717
718 5.3.2.3 FS-Device OSSDe output testing

719 The test pulses of this interface type for testing the transmission line are created and also
720 evaluated on the safety device side. This way the source is able to diagnose the correct
721 functioning of the output stage. In case of any detected error both OSSDe outputs shall be
722 switched to the safe state (Lock-out condition = OFF).
723 The test pulses are created in a periodic manner on both OSSD lines. In order to detect short
724 circuits between the lines or between the lines and power-supply, the test pulses of both lines
725 can be time-shifted to each other (see Figure 19).
OSSD1
ti
ON
OFF
t
TP
OSSD2
Δt c
ON
OFF
t
726
727 Figure 19 – OSSD timings
728 The following parameters specify the characteristics of the test pulses on the OSSD interface:
729 • Period of test pulses ( T P )

730 • Duration of test pulses ( t i )

731 • Time-shift between test pulses of both channels ( Δt c )
732 The characteristics of test pulses are classified in [12]. FS-Devices shall meet type C and
733 class 1 requirements with a test pulse length t i ≤ 1000 µs (see Table 7).
734 5.3.3 Start-up of an FS-Device (Ready pulse)

735 Figure 20 shows the typical start-up sequence of an OSSD sensor without IO-Link Safety
736 capability. During self-test for functional safety, both OSSD signals shall be OFF. When
737 finished, the sensor switches to ON and starts test pulses. A demand causes the sensor to
738 switch OFF. A fault causes the sensor to switch to lock-out condition (OFF) and to remain in
739 this state until repair.
740 NOTE For simplicity, the figure shows only one OSSD channel.
VID
Self-test (RAM, ROM, etc.): usually 2 to 5 s Test pulse
ON state Demand
OFF state OFF state

t
741
742 Figure 20 – Typical start-up of an OSSD sensor
743 Figure 21 shows the start-up of an FS-Device with OSSDe capability connected to a classic
744 FS-DI module.
VID
Self-test (RAM, ROM, etc.): usually 2 to 5 s Test pulse
Ready pulse
ON state Demand
t2R tRO
OFF state OFF state
tRP t
745
746 Figure 21 – Start-up of an FS-Device
747 In contrast to a classic sensor, the FS-Device provides only on pin 4 (see Figure 9) a so-
748 called Ready-pulse of a certain length to indicate the FS-Master its readiness after self-
749 testing. After a certain recovery time, the FS-Device switches to ON and starts test pulses like
750 a classic safety sensor.
751 Timings and Wake-up behavior of the FS-Device are specified in 5.7.
752 5.3.4 Electric characteristics of a receiver in FS-Device and FS-Master

753 The voltage range and switching threshold definitions are the same for FS-Master and FS-
754 Device since FS-Master ports shall be able to operate with non-safety IO-Link Devices. The
755 definitions in Table 6 apply.
756 Table 6 – Electric characteristics of a receiver
Property Designation Minimum Typical Maximum Unit Remark
VTHH D,M Input threshold 10,5 n/a 13 V See NOTE 1

'ON'
VTHL D,M Input threshold 8 n/a 11,5 V See NOTE 1
'OFF'
VHYS D,M Hysteresis between 0 n/a n/a V Shall not be
input thresholds negative
'ON' and 'OFF' See NOTE 2
VIL D,M Permissible voltage V0 D,M -1,0 n/a n/a V With reference to
range 'OFF' relevant negative

supply voltage
VIH D,M Permissible voltage n/a n/a V+ D,M + 1,0 V With reference to
range 'ON' relevant positive
supply voltage.
NOTE 1 Thresholds are compatible with the definitions of type 1 digital inputs in IEC 61131-2.
NOTE 2 Hysteresis voltage VHYS = VTHH - VTHL
757 Figure 22 demonstrates the switching thresholds for the detection of OFF and ON signals.
758 NOTE 'OFF' and 'ON' correspond to 'L' (Low) and 'H' (High) in [1] and [2].
VID,M
V+
Voltage range
'ON'
VTHHMAX
VTHLMAX
Threshold 'ON' VTHHMIN
Threshold 'OFF' VTHLMIN
Voltage range
'OFF'
V0
759
760 Figure 22 – Switching thresholds for FS-Device and FS-Master receivers
761 The FS-Master ignores pulses below 11 V (max. 15 mA or max. 30 mA) that are shorter than
762 1 ms.
763 5.4 Electric and dynamic characteristics of an FS-Device

764 In general, the specified values and ranges of [1] or [2] apply (see Figure 23).
FS-Device Line FS-Master
V+D VD+L V+M

L+ L+
ISD ISM
On/
VRQHD On/
Off IQHD Off
IQPKHD
OVD VRQHM
IQHM
VDQL IQPKHM
H/L C/Q C/Q H/L
VSD VSM
optional 1) VRQLD VRQLM

IQLD IQLM
IQPKLD ILLM IQPKLM
VID VIM
On/ CQD CQM On/
Off Off
OVD
V0D L- VD0L L- V0M

765
766 Figure 23 – Reference schematics (one OSSDe channel)
767 The subsequent illustrations and parameter tables refer to the voltage level definitions in
768 Figure 24.
FS-Device (OSSDe) Line FS-Master

V+M
V+D VD+L VRQHM
VRQHD
VSD VSM
VDQL
VID
VIM
VRQLD
V0D VD0L VRQLM

Output Input
V0M
Input Output
769
770 Figure 24 – Voltage level definitions
771 The electric and dynamic parameters for the OSSDe interface of an FS-Device are specified
772 in Table 7.
773 Table 7 – Electric and dynamic characteristics of the FS-Device (OSSDe)

VS D Supply voltage 18 24 30 V See Figure 24
∆ VS D Ripple n/a n/a 1,3 V pp Peak-to-peak

absolute value limits
shall not be
exceeded. f ripple =
DC to 100 kHz
IS D Supply current n/a n/a 1000 mA See 5.9
QIS D Power-up n/a n/a 70 mAs See equation (1) and

consumption associated text
VRQH D Residual voltage n/a n/a 3 V Voltage drop
'ON' compared with V+ D
(IEC 60947-5-2)
VRQL D Residual voltage n/a n/a 3 V Voltage drop compa-
'OFF' red with V0 D NOTE 1
IQH D DC driver current 50 n/a minimum mA Minimum value due to

P-switching output (IQPKL M ) fallback to digital
('ON' state) input in accordance
with IEC 61131-2,
type 2
IQL D DC driver current 0 n/a minimum mA Only for push-pull
N-switching output (IQPKH M ) output stages
('ON' state)
IQQ D Quiescent current 0 n/a 15 mA Pull-down or residual

to V0 D current with
('OFF' state) deactivated output
driver stages
CQ D Input capacitance 0 n/a 1,0 nF Effective capacitance
between C/Q and L+
or L- of Device in
receive state. See [1]
for constraints on
transmission rates.
t 2R Time to Ready- n/a n/a 5 s See Figure 21;

pulse Parameter in IODD
t RP Duration of Ready 500 n/a 1000 µs See Figure 21

pulse
t RW End of Ready n/a n/a 50 µs See Figure 27 –

pulse to ready for Start-up of an FS-
Wake-up Device
t RO End of Ready 700 n/a Data sheet µs See Figure 21

pulse to OSSD
mode
TP Period of test 10 n/a Data sheet ms See [12] and Figure

pulses 19
ti Test pulse n/a n/a 1000 µs See Figure 19.

duration
t dis Discrepancy time n/a n/a 3 ms Demands may occur

during tests
NOTE 1 Pull-down of residual voltage with deactivated high-side output driver stage and activated low-side driver
stages (if available e.g. push-pull drivers) with externally limited DC driver current of 50 mA maximum
NOTE 2 Characteristics in this table assume OSSD type "C", class "1" according to [12] and interface type 1
according to IEC 61131-2
774
775 It is the responsibility of the FS-Device designer to select appropriate ASICs according to [1]
776 and/or to provide mitigating circuitry to meet the requirements of IEC 61496-1.
777 The FS-Device shall be able to reach a stable operational state (ready for Wake-up: T RDL )
778 while consuming the maximum charge (see equation (1)).
QIS D = ISIR M × 50ms + (T RDL − 50 ms ) × IS M (1)
779
780 5.5 Electric and dynamic characteristics of an FS-Master port (OSSDe)

781 In general, the specified values and ranges of [1] or [2] apply (see Figure 23 and Figure 24).
782 The definitions in Table 8 are valid for the electrical characteristics of an FS-Master port.
783 Table 8 – Electric and dynamic characteristics of the Port interface
VS M Supply voltage for 20 24 30 V See Figure 24

FS-Devices
IS M Supply current for 200 n/a 1000 mA Rules in 5.9. shall
FS-Devices be considered
ISIR M Current pulse 400 n/a n/a mA See Figure 25
capability for FS-
Devices
ILL M Load or discharge See NOTE 1
current for
0 V < VI M < 5 V 0 n/a 15 mA
5 V < VI M < 15 V 5 n/a 15 mA
15 V< VI M < 30 V 5 n/a 15 mA
VRQH M Residual voltage n/a n/a 3 V Voltage drop

'H' 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
IQH M DC driver current 100 n/a n/a mA

'H'
IQPKH M Output peak 500 n/a n/a mA Absolute value
current 'H' See NOTE 2
IQL M DC driver current 100 n/a n/a mA
'L'
IQPKL M Output peak 500 n/a n/a mA Absolute value
current 'L' See NOTE 2
CQ M Input capacitance n/a n/a 1,0 nF f=0 MHz to 4 MHz
NOTE 1 Currents are compatible with the definition of type 1 digital inputs in IEC 61131-2. However, for the
range 5 V < VI M < 15 V, the minimum current is 5 mA instead of 2 mA in order to achieve short enough slew
rates for pure p-switching Devices.
NOTE 2 Wake-up request current (See 5.3.3.3 in [1] or [2]).
784
785 The Master shall provide a charge of at least 20 mAs within the first 50 ms after power-on
786 without any overload-shutdown (see Figure 25). After 50 ms the current limitations for IS M in
787 Table 8 apply.
ISM
Master can provide higher currents
ISIRM min
ISM min
Minimum current the Master shall provide
Device
specific
behavior
50 ms t
788
789 Figure 25 – Charge capability at power-up
790 5.6 FS-Master port FS-DI interface

791 Since OSSD safety sensors can provide different test pulse patterns, the FS-Master Port shall
792 have a suitable input filter, or evaluation algorithm. For the sake of EMC considerations, by a
793 combination of both can be used. This means, that the time, in which the signal is below
794 U Hmin must be less than the maximum allowed test pulse duration.
795 Any state different to both signals "high", except test pulses, shall be interpreted as safe
796 state.
797 NOTE Achievable reaction times: IO-Link non safe: min. 600 μs, PROFINET: 1 ms, non-synchronized system:
798 2 ms
799 The EMC levels shall be taken into account for the layout of an input filter. The
800 communication transmission rate 230 kbit/s conflicts with the input filter. Possible conflict
801 resolution is shown in Figure 26.
Communication
Line with
test pulses
OSSD
802
803 Figure 26 – OSSDe input filter conflict resolution
804 In general, the specified values and ranges of [1] or [2] apply. Basis is interface type 1 of IEC
805 61131-2. Deviating and supplementary electric and dynamic parameters for the FS-DI
806 interfaces are specified in Table 8.
807 5.7 Wake-up coordination

808 Figure 27 shows the start-up of an FS-Device (see [1] for standard timing definitions). After
809 accomplished self-tests, it indicates its readiness for Wake-up through an ON/Ready pulse on
810 the C/Q line. If no Wake-up occurs within a defined time frame, it starts with test pulses (see
811 Figure 20).
VSD Power-up
18 V min.
Ready for wake-up
t
TRDL = 300 ms max. WURQ:
Ready TREN = 0,5 ms max.
VID
Self-test (RAM, ROM, etc.): pulse
usually 2 to 5 s TDWU = 50 ms max.
tRW IO-Link communication

OFF state
t
812
813 Figure 27 – Start-up of an FS-Device

814 NOTE Actually some safety light curtain vendors offer activation of functionality if some connection conditions are
815 activated during start-up phase (e.g. override)
816 5.8 Fast start-up
817 Figure 28 illustrates required fast start-up non-safety and safety timings.
Fieldbus + FSCP
Fast start-up (non safety) Fast start-up (safety)
0,5 s 1s t
818
819 Figure 28 – Required fast start-up timings
820 Current safety devices usually require 2 to 5 seconds for self-testing prior to functional safe
821 operation. The Ready-pulse concept allows for easier achievable realizations of these
822 requirements.
823 5.9 Power supply

824 An FS-Master port shall be able to switch its power supply on and off. This enables the FS-
825 Master to restart an FS-Device once it failed to establish communication and started OSSDe
826 operation instead.
827 The FS-Master port is the only power supply for IO-Link related parts of the FS-Device. Any
828 external power source of the FS-Device shall be totally nonreactive to these parts.
829 FS-Master shall provide all ports with a minimum supply of 200 mA and at least one port with
830 a minimum supply of 1000 mA. The FS-Master shall specify the total maximum current
831 consumption of all its ports and the derating rules.
832 Higher currents can conflict with the power switching components and cause interference with
833 the signal lines. The "ripple" requirement in Table 7 shall be considered. The overall cable
834 loop resistance shall be not more than 1,2 Ω (see Table 8 and Table 9).
835 5.10 Medium

836 5.10.1 Constraints
837 For the sake of simplicity in technology and commissioning, IO-Link Safety expects a wired
838 point-to-point connection or equivalent consistent transmission and powering between FS-
839 Master and an FS-Device. No storing elements in between are permitted.
840 5.10.2 Connectors

841 Connectors as specified in [1] for Class A are permitted.
842 5.10.3 Cable characteristics

843 Table 9 shows the cable characteristics for IO-Link Safety and non-safety Devices, if higher
844 power supply currents than 200 mA are applied.
845 Table 9 – Cable characteristics
Property Designation Minimum Typical Maximum Unit
L Cable length 0 n/a 20 m
RL eff Overall loop resistance n/a n/a 1,2 Ω
CL eff Effective line capacitance n/a n/a 3,0 nF (<1 MHz)
NOTE These characteristics can deviate from the original characteristics defined in [1] or [2].
846
847 6 Extensions to SIO

848 SIO is only defined for Pin 4 of the Master/Device port in [1]. OSSDe requires inclusion of
849 Pin 2 as specified in clause 5. Configuration can be performed within the Master/Device
850 applications layer (see Figure 31 and Figure 35).
851 7 Extensions to data link layer (DL)

852 7.1 Overview
853 Figure 31 and Figure 35 show the DL building blocks of FS-Device and FS-Master. No new or
854 changed services are required. However, both DL-mode handlers are extended by the Ready-
855 pulse feature as shown in 7.2 and 7.3.
856 7.2 State machine of the FS-Master DL-mode handler

857 Figure 29 shows the modifications of the FS-Master DL-mode handler versus the Master DL-
858 mode handler in [1].
859 A new state "WaitOnReadyPulse_10" considers the requirement for the FS-Master to wait on
860 the Ready-pulse of an FS-Device (see 5.7) prior to establish communication via
861 DL_SetMode_STARTUP.
862 The maximum waiting time is t 2R as defined in Table 7. Whenever the time expired, the FS-
863 Master shall run a power-OFF/ON cycle for the connected FS-Device in order to initiate a
864 retry for another Ready-pulse.
865 The criterion to use the extra path is the guard [safety], which is derived from the new port
866 configuration "FS_PortModes" (see 10.2.2).
/Initialization
DL_SetMode_INACTIVE/ DL_SetMode_INACTIVE/
T8 T13
Idle_0
[Safety]/
T20
DL_SetMode_STARTUP WaitOnReadyPulse_10
tm(5000)/
[Non-safety]/
T22
T1
DL_SetMode_STARTUP
[Ready pulse OK]/
T21
EstablishCom_1
[Retry = 3]/
Submachine 1 T5
"WakeUp" enex_4
enex_1 enex_2 enex_3
[Response [Response [Response MHInfo_COMLOST/

COM3]/ COM2]/ COM1]/ T14
T2 T3 T4
Startup_2
MHInfo_COMLOST/
T9 DL_SetMode_
STARTUP/
T12
DL_SetMode DL_SetMode_PRE
OPERATE/ DL_SetMode
_STARTUP/
T6 _OPERATE/
T7
T11
PreOperate_3 Operate_4
DL_SetMode_OPERATE/
T10
867
868 Figure 29 – State machine of the FS-Master DL-mode handler
869 Table 10 shows the additional state and transitions as well as internal items considering the
870 Ready-pulse feature.
871 Table 10 – State transition tables of the FS-Master DL-mode handler
STATE NAME STATE DESCRIPTION
Idle_0 to SM: Retry_9 See Table 42 in [1]

WaitOnReadyPulse_10 Waiting on the Ready-pulse from the FS-Device. A timer of 5 s is started.
872
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 to T19 * * See Table 42 in [1]

T20 0 10 This path is taken only if the new configuration parameter "Safety" has
been assigned to "SafetyCom" or "MixedSafetyCom" respectively
T21 10 1 Set Retry = 0.
T22 10 0 FS-Master was not able to detect a Ready-pulse within 5 s. It will initiate a
power OFF/ON cycle for the FS-Device to retry the Ready-pulse.
873
INTERNAL ITEMS TYPE DEFINITION
MH_xxx to xx_Conf… Call See Table 42 in [1]

Safety Guard New configuration parameter "Safety": either value "SafetyCom" or
"MixedSafetyCom"
Ready pulse OK Guard Ready-pulse detected
874
875 7.3 State machine of the FS-Device DL-mode handler

876 Figure 30 shows the modifications of the FS-Device DL-mode handler versus the Device DL-
877 mode handler in [1].
/Initialization
SelfTesting_5
Ready_Pulse[
SelfTesting OK]/
T13
[MCmd_FALLBACK]/ [MCmd_FALLBACK]/
T8 T9
Idle_0
tm(Tdsio)/ PL_WakeUp/
T10 T1
EstablishCom_1
[Successful COMx]/
T2 MHInfo_ILLEGAL_MESSAGETYPE/
T11
Startup_2
MHInfo_ILLEGAL_MESSAGETYPE/ [MCmd_STARTUP]/
T12 T7
[MCmd_OPERATE]/
T5
[MCmd_STARTUP]/
T6 [MCmd_PREOPERATE]/
T3
PreOperate_3 Operate_4
[MCmd_OPERATE]/
T4
878
879 Figure 30 – State machine of the FS-Device DL-mode handler
880 A new state "SelfTesting_5" considers the requirement for the FS-Device to indicate its
881 readiness for a wake-up procedure after its internal safety self-testing via a test pulse in pin 4.
882 Self-testing may actually take more than the maximum permitted start-up time T RDL of a non-
883 safety Device (see 5.7).
884 Table 11 – State transition tables of the FS-Device DL-mode handler
Idle_0 to Operate_4 See Table 43 in [1]

SelfTesting_5 Safety check through self-testing of µC, RAM, etc. This may take more than the
permitted start-up time T RDL of a non-safety Device.
885
TRANSITION SOURCE TARGET ACTION
STATE STATE
T1 to T12 * * See Table 43 in [1]

T13 5 0 Create a signal (Ready_Pulse) on pin 4 for duration of t RP , when self-
testing is completed.
886
T RDL Time See Table 7 10 in [1]
t RP Time See Table 7
Self-testing OK Guard Self-testing completed

887 8 Extensions to system management (SM)

888 There are no extensions to system management.
889 9 Extensions of the FS-Device

890 9.1 Principle architecture and models
891 9.1.1 FS-Device architecture
892 Figure 31 shows the principle architecture of the FS-Device. It does not include safety
893 measures for implementation such as redundancy for the safety-related parts.
Device applications
Technology specific safety application (technology parameter, diagnosis, process data) Safety Layer Manager
Parameter Manager Data Storage Event Dispatcher Process Data Safety Com
OSSDe
(PM) (DS) (ED) Exchange (PDE) Layer (SCL)
AL_NewOutput
AL_GetOutput
AL_PDCycle
AL_SetInput
AL_Control
AL_Event
AL_Read
AL_Abort
AL_Write
DI DI
(OSSDe) (OSSDe)
On-request Data Process Data

SM_SetDevciceIdent
SM_SetDeviceMode
SM_GetDeviceIdent
AL
SM_GetDeviceCom
SM_SetDeviceCom
objects Application Layer objects

SM_DeviceMode
DL_PDOutput-
DL_PDInput-
DL_PDCycle
DL_Control
DL_Event-
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
Trigger
Update
Param
Param
Abort

Line
Handler
handler handler
PDInStatus
DL-B
EventFlag
DL_Read
OD.rsp
OD.ind
PD.rsp
PD.ind
DL-A
DL_Write
Device
System DL_Mode DL-mode MHInfo Message
manage- handler
ment handler
DI DI
PL_SetMode.req PL_Ready.req PL_WakeUp.ind PL_Transfer.ind PL_Transfer.req
Mode switch
Ready/Wake-up Coded switching Switching signals
Physical layer
894
895 Figure 31 – Principle architecture of the FS-Device
896 An FS-Device comprises first of all the technology specific functional safety application.
897 "Emergency switching off" safety devices for example can be designed such that "classic"
898 OSSDe operation or safety communication can be configured. A Safety Layer Manager is
899 responsible for the handling of a safety bit via the OSSDe building block or a safety PDU
900 using the Safety Communication Layer (see clause 11).
901 9.1.2 FS-Device model

902 According to the requirement of mixed NSR and SR parameter and process data, the FS-
903 Device model has been modified and adapted.
904 That means the FS-Device Index model is split into an NSR and an SR part. Figure 32 shows
905 the areas of concern. The allocation of the SR part ("FSP" parameter) is defined within the
906 IODD of the FS-Device.
907 During commissioning, the assignment of FSP parameter values take place. These instance
908 values are secured by CRC signatures and transferred as a block to the FS-Master and to the
909 FS-Device (see 11.7.5). At each start-up of an FS-Device, the stored FSP block in the FS-
910 Master is transferred again and the FS-Device can check the locally stored instance
911 parameter values for integrity via CRC signatures. This check includes technology specific
912 "FST" parameters, which are not transferred at each start-up. The FS-Device displays its FSP
913 parameters at predefined Indices read-only.
914 Technology specific parameters (FST) could be handled either in an open manner to a certain
915 extend as standard non-safety parameters (see 11.7.8) or in a protected manner in hidden
916 internal memory (see 11.7.9).
Second level protected

Process data internal memory
Parameter and
commands FST parameters
0...32
octets Via transfer (type "complex")
in 232 0 Index
0xFFFF
Index 0...65535,
232 octets/index
Subindex 1...255
maximum
 selective
51 10 5 Event memory
(diagnosis)
FS-IO data
and 0...32
232
Subindex 0
0
0...32
non FS-IO data octets
out
 entire record
octets
...
Direct Parameter
0x00 page 1+2
15 0
FSP parameters FST parameters

(read only) (type "basic")
917
918 Figure 32 – The FS-Device model
919 The maximum space for FS-I/O data and non FS-I/O data to share is 32 octets. The space
920 shall be filled with FS-I/O data first followed by the non FS-I/O data. The border is variable.
921 Assuming a maximum safety protocol trailer of 5 octets, the maximum possible space for FS-
922 I/O data is 27 octets.
923 9.2 Parameter Manager (PM)

924 There are no extensions or modifications of the Parameter Manager required.
925 9.3 Process Data Exchange (PDE)

926 Depending on "Safety" configuration, Process Data Exchange takes over or passes FS-
927 Process Data (see 11.4.3 Safety PDU) from/to the Safety Layer Manager.
928 9.4 Data Storage (DS)

929 9.4.1 General considerations including safety
930 The technology specific (FST) parameters are secured by a particular CRC signature
931 (FSP_TechParCRC) included in the FSP parameter set. Additional Authenticity parameters
932 are used in case of FS-Device replacement. Thus, the standard Data Storage mechanism can
933 be used for FS-Device replacement. This document specifies a straighter forward version of
934 standard Data Storage compliant with [1].
935 This version of Data Storage requires that Device Access Lock (Index 0x000C) bit "0" and "1"
936 shall always be unlocked (= "0").
937 9.4.2 User point of view

938 The Data Storage mechanism for FS-Devices is based on the general mechanism for non-
939 safety-related Devices. It is described here from a holistic user's point of view as best practice
940 pattern (system description). This is in contrast to current [1] or [2], where Device and Master
941 are described separately and with more features then used within this concept.
942 9.4.3 Operations and preconditions for Device replacement

943 9.4.3.1 Purpose and objectives
944 Main purpose of the IO-Link Data Storage mechanism is the replacement of obviously defect
945 Devices or Masters by spare parts (new or used) without using configuration, parameteriza-
946 tion, or other tools. The scenarios and associated preconditions are described in the following
947 clauses.
948 9.4.3.2 Preconditions for the activation of the Data Storage mechanism
949 The following preconditions shall be observed prior to the usage of Data Storage:
950 (1) Data Storage is only available for Devices and Masters implemented according to [1] or
951 [2] or later releases (> V1.1).
952 (2) The Inspection Level of that Master port the Device is connected to shall be adjusted to
953 "type compatible" (corresponds to "TYPE_COMP" within Table 78 in [1]).
954 (3) The Backup Level of that Master port the Device is connected to shall be either "Back-
955 up/Restore" or "Restore", which corresponds to DS_Enabled in 11.2.2.6 in [1]. See 9.4.5
956 within this document for details on Backup Level.
957 9.4.3.3 Preconditions for the types of Devices to be replaced
958 After activation of a Backup Level (Data Storage mechanism) a "faulty" Device can be re-
959 placed by a type equivalent or compatible other Device. In some exceptional cases, for exam-
960 ple non-calibrated Devices, a user manipulation is required such as teach-in, to guarantee the
961 same functionality and performance.
962 Thus, two types of Devices exist in respect to exchangeability, which shall be described in the
963 user manual of the particular Device:
964 Data Storage class 1: automatic DS
965 The configured Device supports Data Storage in such a manner that the replacement Device
966 plays the role of its predecessor fully automatically and with the same performance.
967 Data Storage class 2: semi-automatic DS
968 The configured Device supports Data Storage in such a manner that the replacement Device
969 requires user manipulation such as teach-in prior to operation with the same performance.
970 9.4.3.4 Preconditions for the parameter sets

971 Each Device operates with the configured set of active parameters. The associated set of
972 backup parameters stored within the system (Master and upper level system, for example
973 PLC) can be different from the set of active parameters (see Figure 33).
974 A replacement of the Device in operation will result in an overwriting of the existing
975 parameters within the newly connected Device by the backup parameters.
976
Parameter
PLC / Host server
(Master backup
parameter)
Master
Port 1 Port 2 Port n

Data Storage
(Device backup
parameter)
Device Device Device
Application Application Application Active

parameter
977
978 Figure 33 – Active and backup parameter
979 9.4.4 Commissioning

980 9.4.4.1 On-line commissioning
981 Usually, the Devices are configured and parameterized along with the configuration and pa-
982 rameterization of the fieldbus and PLC system with the help of engineering tools. After the
983 user assigned values to the parameters, they are downloaded into the Device and become
984 active parameters. Upon a system command, these parameters are uploaded (copied) into the
985 Data Storage within the Master, which in turn will initiate a backup of all its parameters de-
986 pending on the features of the upper level system.
987 In case of functional safety, commissioning cannot be completed without verification and
988 validation of FSP and FST parameters as well as of entire safety functions according to the
989 relevant safety manuals.
990 9.4.4.2 Off-site commissioning

991 Another possibility is the configuration and parameterization of Devices with the help of extra
992 tools such as "USB-Masters" and the IODD of the Device away (off-site) from the machine/
993 facility (see Figure 34).
994 The "USB-Master" tool will arm the parameter set after configuration, parameterization, and
995 validation (to become "active") and mark it via a non-volatile flag (see Table 13). After in-
996 stallation in the machine/facility these parameters are uploaded (copied) automatically into
997 the Data Storage within the Master (backup).
"USB Master"
Tool software
IODD
Parameter Test
Device
998
999 Figure 34 – Off-site commissioning
1000 9.4.5 Backup Levels

1001 9.4.5.1 Purpose
1002 Within an automation project with IO-Link usually three situations with different user require-
1003 ments for backup of parameters via Data Storage can be identified:
1004 • commissioning ("Disable");

1005 • production ("Backup/Restore");

1006 • production ("Restore").
1007 Accordingly, three different "Backup Levels" are defined allowing the user to adjust the sys-
1008 tem to the particular functionality such as for Device replacement, off-site commissioning, pa-
1009 rameter changes at runtime, etc.
1010 These adjustment possibilities lead for example to drop-down menu entries for "Backup Lev-
1011 el".
1012 9.4.5.2 Overview

1013 Table 12 shows the recommended practice for Data Storage within an IO-Link system. It sim-
1014 plifies the activities and their comprehension since activation of the Data Storage implies
1015 transfer of the parameters.
1016 Table 12 – Recommended Data Storage Backup Levels
Backup Level Data Storage adjustments Behavior
Commissioning Master port: Activation state: "DS_Cleared" Any change of active parameters within the
("Disable") Device will not be copied/saved.
Device replacement without automatic/semi-
automatic Data Storage.
Production Master port: Activation state: "DS_Enabled" Changes of active parameters within the
("Backup/Restore") Master port: UploadEnable Device will be copied/saved.
Master port: DownloadEnable Device replacement with automatic/semi-
automatic Data Storage supported.
Production Master port: Activation state: "DS_Enabled" Any change of active parameters within the
("Restore") Master port: UploadDisable Device will not be copied/saved. If the
parameter set is marked to be saved, the
Master port: DownloadEnable "frozen" parameters will be restored by the
Master.
However, Device replacement with auto-
matic/semi-automatic Data Storage of
frozen parameters is supported.
1017 Legacy rules and presetting:
1018 • For Devices according to [1] with preset Inspection Level "NO_CHECK" only the Backup
1019 Level "Commissioning" shall be supported. This should also be the default presetting in
1020 this case.
1021 • For Devices according to [1] with preset Inspection Level "TYPE_COMP", all three Backup
1022 Levels shall be supported. Default presetting in this case should be "Backup/Restore".
1023 • For Devices according to [1] with preset Inspection Level "IDENTICAL", only the Backup
1024 Level "Commissioning" shall be supported.
1025 The following clauses describe the phases in detail.
1026 9.4.5.3 Commissioning ("Disable")

1027 The Data Storage is disabled while in commissioning phase, where configurations, parameter-
1028 izations, and PLC programs are fine-tuned, tested, and verified. This includes the involved IO-
1029 Link Masters and Devices. Usually, saving (upload) the active Device parameters makes no
1030 sense in this phase. As a consequence, the replacement of Master and Devices with au-
1031 tomatic/semi-automatic Data Storage is not supported.
1032 9.4.5.4 Production ("Backup/Restore")

1033 The Data Storage will be enabled after successful commissioning. Current active parameters
1034 within the Device will be copied (saved) into backup parameters. Device replacement with
1035 automatic/semi-automatic Data Storage is now supported via download/copy of the backup
1036 parameters to the Device and thus turning them into active parameters.
1037 Criteria for the particular copy activities are listed in Table 13. These criteria are the condi-
1038 tions to trigger a copy process of the active parameters to the backup parameters, thus
1039 ensuring the consistency of these two sets.
1040 Table 13 – Criteria for backing up parameters ("Backup/Restore")
User action Operations Data Storage
Commissioning session Parameterization of the Device via Master Master tool sends ParamDownloadStore;
(see 9.4.4.1) tool (on-line). Transfer of active parame- Device sets "DS_Upload" flag and then
ter(s) to the Device will cause backup triggers upload via "DS_UPLOAD_REQ"
activity. Event. "DS_Upload" flag is deleted as
soon as the upload is completed.
Switching from commis- Restart of Port and Device because Port During system startup, the "DS_Upload"
sioning to production configuration has been changed flag triggers upload (copy).
"DS_Upload" flag is deleted as soon as
the upload is completed
Local modifications Changes of the active parameters through Device technology application sets
teach-in or local parameterization at the "DS_Upload" flag and then triggers up-
Device (on-line) load via "DS_UPLOAD_REQ" Event.
the upload is completed.
Off-site commissioning Phase 1: Device is parameterized off-site Phase 1: "USB-Master" tool sends
(see 9.4.4.2) via "USB-Master" tool (see Figure 34). ParamDownloadStore; Device sets
Phase 2: Connection of that Device to a "DS_Upload" flag (in non-volatile
Master port. memory) and then triggers upload via
"DS_UPLOAD_REQ" Event, which is
ignored by the "USB-Master".
Phase 2: During system start-up, the
"DS_Upload" flag triggers upload (copy).
Changed port configura- Whenever port configuration has been Change of port configuration to different
tion (in case of "Back- changed via Master tool (on-line): e.g. VendorID and/or DeviceID as stored
up/Restore" or "Re- Configured VendorID (CVID), Configured within the Master triggers "DS_Delete"
store") DeviceID (CDID), see 11.2.2 in [1]. followed by an upload (copy) to Data
Storage (see 11.8.2, 11.2.1 and 11.3.3
in [1]).
PLC program demand Parameter change via user program fol- User program sends SystemCommand
lowed by a SystemCommand ParamDownloadStore; Device sets
"DS_Upload" flag and then triggers up-
load via "DS_UPLOAD_REQ" Event.
1041
1042 9.4.5.5 Production ("Restore")

1043 Any changes of the active parameters through teach-in, tool based parameterization, or local
1044 parameterization shall not lead automatically to a download ("restore") of the entire parameter
1045 set; the upload can be disabled.
1046 Criteria for the particular copy activities are listed in Table 14. These criteria are the condi-
1047 tions to trigger a copy process of the active parameters to the backup parameters, thus ensu-
1048 ring the consistency of these two sets.
1049 Table 14 – Criteria for backing up parameters ("Restore")
User action Operations Data Storage
Change port configura- Change of port configuration via Master Change of port configuration triggers
tion tool (on-line): e.g. Configured VendorID "DS_Delete" followed by an upload
(CVID), Configured DeviceID (CDID); see (copy) to Data Storage; see 11.8.2,
11.2.2.5 in [1]. 11.2.1 and 11.3.3 in [1].
1050
1051 9.4.6 Use cases

1052 9.4.6.1 Device replacement (@ "Backup/Restore")
1053 The stored (saved) set of back-up parameters overwrites the active parameters (e.g. factory
1054 settings) within the replaced compatible Device of same type. This one operates after a re-
1055 start with the identical parameters as its predecessor.
1056 The preconditions for this use case are
1057 (1) Devices and Master port adjustments according to 9.4.3.2;

1058 Backup Level: "Backup/Restore"
1059 The replacement Device shall be re-initiated to "factory settings" in case it is not a new
1060 Device out of the box (for "factory reset" see 10.6.4 in [1])
1061 9.4.6.2 Device replacement (@ "Restore")
1062 The stored (saved) set of back-up parameters overwrites the active parameters (e.g. factory
1063 settings) within the replaced compatible Device of same type. This one operates after a re-
1064 start with the identical parameters as its predecessor.
1065 The preconditions for this use case are
1066 (1) Devices and Master port adjustments according to 9.4.3.2;

1067 Backup Level: "Restore"
1068 9.4.6.3 Master replacement
1069 9.4.6.3.1 General
1070 This feature depends heavily on the implementation and integration concept of the Master de-
1071 signer and manufacturer as well as on the features of the upper level system (fieldbus).
1072 9.4.6.3.2 Without fieldbus support (base level)

1073 Principal approach for a replaced (new) Master using a Master tool:
1074 (1) Set port configurations: amongst others the Backup Level to "Backup/Restore" or "Re-
1075 store"
1076 Master "reset to factory settings": clear backup parameters of all ports within the Data Storage
1077 in case it is not a new Master out of the box
1078 Active parameters of all Devices are automatically uploaded (copied) to Data Storage
1079 (backup)
1080 9.4.6.3.3 Fieldbus support (comfort level)
1081 Any kind of fieldbus specific mechanism to back up the Master parameter set including the
1082 Data Storage of all Devices is used. Even though these fieldbus mechanisms are similar to
1083 the IO-Link approach, they are following their certain paradigm which may conflict with the
1084 described paradigm of the IO-Link back up mechanism (see Figure 33).
1085 9.4.6.3.4 PLC system

1086 The Device and Master parameters are stored within the system specific database of the PLC
1087 and downloaded to the Master at system startup after replacement.
1088 This top down concept may conflict with the active parameter setting within the Devices.
1089 9.4.6.4 Project replication

1090 Following the concept of 9.4.6.3.3, the storage of complete Master parameter sets within the
1091 parameter server of an upper level system can automatically initiate the configuration of Ma-
1092 sters and Devices besides any other upper level components and thus support the automatic
1093 replication of machines.
1094 Following the concept of 9.4.6.3.4, after supply of the Master by the PLC, the Master can
1095 supply the Devices.
1096 10 Extensions of the FS-Master

1097 10.1 Principle architecture
1098 Figure 35 shows the principle architecture of the FS-Master.
Master applications
Gateway application (configuration, parameterization, diagnosis, on-request, and process data) Safety Layer Manager
Configuration Data Storage On-request Data Diagnosis Unit Process Data Safety Com
OSSDe
Manager (CM) (DS) Exchange (ODE) (DU) Exchange (PDE) Layer (SCL)
AL_SetOutput
AL_NewInput
AL_PDCycle
AL_GetInput
AL_Control
AL_Event
DI
AL_Read
AL_Abort
DI
AL_Write
(OSSDe) (OSSDe)
SM_GetPortConfig
SM_SetPortConfig
SM_PortMode
SM_Operate

AL
objects Application Layer objects
DL_PDInput-
DL_PDCycle
DL_PDOut-
DL_Control
DL_Event-
putUpdate
DL_ISDU-
DL_ISDU-
DL_Read-
DL_Write-
DL_Event
Transport
Transport
AL_Read
Param
Param
Port x
Abort
Conf
Handler
DL_Read On-request Data Process Data

Coordi- handler handler
DL_Write
nation
DL_SetMode
DL-B
PDInStatus
Data Link Layer

EventFlag
ODTrig
PD.req
PDTrig
OD.req
PD.cnf
OD.cnf
DL-A
Master
DL_Mode DL-mode MHInfo Message
System
handler handler
management
DI DI
PL_SetMode.req PL_Ready.ind PL_WakeUp.req PL_Transfer.req PL_Transfer.ind
Mode switch
Inactive Ready/Wake-up Coded switching Switching signal
Physical layer (port)
1099
1100 Figure 35 – Principle architecture of the FS-Master
1101 Core part of an FS-Master is the original standard Master except for the Ready-pulse and its
1102 handling (see 5.3.3 and 7.2). The Master applications have been extended by a Safety Layer
1103 Manager dealing with safety communication (see clause 11) and OSSDe.
1104 10.2 Safety Layer Manager (SLM)

1105 10.2.1 Purpose
1106 The Safety Layer Manager takes care of the safety PDU, whenever safety communication has
1107 been configured or of one safety bit, whenever OSSDe has been configured for a particular
1108 port.
1109 It holds the FSP parameter block consisting of the authenticity record and the protocol record
1110 (see 11.7.5) as well as the FS I/O structure description (see Table A.1 and E.5.5).
1111 10.2.2 FS_PortModes

1112 The FS-Master shall support five FS_PortModes adjustable via the FS-Master Tool.
1113 NonSafetyCom
1114 This setting enables pure IO-Link communication with only NSR Process Data of a port.
1115 SafetyCom
1116 This setting enables pure safety communication without NSR Process Data of a port.
1117 MixedSafetyCom
1118 This setting enables safety communication of SR and NSR Process Data of a port.
1119 OSSDe
1120 This setting enables OSSDe operation of a port.
1121 SIO
1122 This setting enables SIO operation of a port.
1123 10.2.3 FSP parameter blocks

1124 10.2.3.1 FSP parameter use cases
1125 Figure 36 illustrates some use cases related to the FSP parameters (see A.1).
1126
1127 Figure 36 – FSP parameter use cases
1128 Table 15 shows a listing of the items in Figure 36 and references to clauses within this
1129 document or to other IO-Link specifications (bibliography).
1130 Table 15 – Use case reference table
No. Item Type Reference Remarks
0 User Roles: – Responsibility of the

- Observer software tool
- Maintenance manufacturer
- Specialist
1 FSP_Interpreter GUI-functions E.g. Figure 56
2 IODD (secured) Device description Annex E
3 IODD_Import Activity Annex E
4 Password Activity Clause 10.2.3.2 Role dependent
5 FSP_Authent Activity Clause 11.7.5
6 FS_IO_Structure FS I/O description Annex A.1
7 FSP_Protocol Activity Clause 11.7.6
8 ProjectDatabase FS-Master Tool – Proprietary
9 Default_watchdog_value Activity Annex A.2.6
10 PropCom (not standardized) Communication Clause 10.2.3.1 Proprietary
11 PropCom (not standardized) Communication Clause 10.2.3.1 Proprietary
12 Safety_Layer_Manager Activity Clause 10.2
13 FSCP_Authentication Activity Clause 11.7.5
No. Item Type Reference Remarks
14 FS_IO_Data_Mapper Gateway application Clause 12.1 FSCP Integration

15 FSP_Authent+Protocol FS-Master SCL Clause 11.5.2
16 Non-volatile memory FS-Master – Implementation
17 FSP_Authent+Protocol Transfer Clause 11.5.3
18 ISDU-Handler FS-Master DL [1] IO-Link standard
19 ISDU-Handler FS-Device DL [1] IO-Link standard
20 Index_memory Activity [1] IO-Link standard
21 FSP_Authent+Protocol Activity Clause 11.5.3
22 Non-volatile memory FS-Device – Implementation
1131
1132 In the following, a typical parameterization session of a project in the ProjectDatabase is

1133 described, where a new FS-Device is planned, configured, and parameterized for a particular
1134 port. After installation of IODD and associated Dedicated Tool, the user of an FS-Master Tool
1135 opens the parameter tab page (see illustration in Figure 56). After entry of the password for
1136 safety projects (see 10.2.3.2), FSP parameters are enabled to be displayed and Dedicated
1137 Tools are enabled to be launched.
1138 The authenticity parameter values carry "0" as default within the IODD of an FS-Device. For
1139 details see 10.2.3.3.
1140 The IODD contains the I/O data structure description of the safety Process Data as a record
1141 secured by CRC signature (see A.2.9 and E.5.6).
1142 Most of the protocol parameter values are preset by default values provided by the FS-Device
1143 manufacturer within the IODD, except for the value of FSP_TechParCRC, which has a
1144 particular responsibility. A value of "0" means commissioning/test (see Annex G). The
1145 consequences are
1146 • No validity check of technology parameters at start-up

1147 • No blocking of FSP authenticity parameter acceptance within the FS-Device
1148 • No Data Storage
1149 Any value not equal to "0" will arm all three activities. For details see 10.2.3.4.
1150 After parameter assignment, the FSP parameter instance values can be stored in the
1151 ProjectDatabase.
1152 When online, the FS-Master Tool uses a proprietary communication ("PropCom") to the FS-
1153 Master (not standardized in [1]). Any transmission error (see Table 16) can falsify the
1154 message bits and thus, each FSP parameter record is secured by CRC signature.
1155 NOTE Standardization of "PropCom" is responsibility of IO-Link integration into a fieldbus.
1156 Upon power-on, the Safety Layer Manager of the FS-Master acquires the FSCP authenticity
1157 code and stores the values. The FS-Master Tool reads these values and replaces the default
1158 "0" by the actual FSCP authenticity code and assigns a port number ≠0. A CRC signature
1159 calculation secures the entire FSP authenticity parameter record. All three records, FSP
1160 authenticity, FSP protocol, and I/O structure description can be transferred to the Safety
1161 Layer Manager of the FS-Master.
1162 NOTE The activities described above assume an FSP_TechParCRC value of "0" (commissioning).
1163 The Safety Layer Manager propagates the I/O structure description record to the
1164 FS_IO_DataMapper. The FSP authenticity and FSP protocol records are propagated to the
1165 local FS-Master safety communication layer (SLC) and in PREOPERATE state to the FS-
1166 Device safety communication layer (SLC). The FS-Device accepts the authenticity code and
1167 stores it locally.
1168 From now on the IO-Link Safety system is able to run in "monitored operational mode". That
1169 means personnel are required to watch the machine.
1170 The user is now able to enter and test the technology specific parameters (see illustration in
1171 Figure 56). After verification and validation, the user launches the Dedicated Tool, confirms
1172 the value assignments and transfers the CRC signature to the FSP_TechParCRC field. With a
1173 value of ≠ "0", the system can be armed:
1174 • Data Storage
1175 • Blocking of FSP authenticity parameter acceptance within the FS-Device (comparison
1176 only)
1177 • Validity check of authenticity and technology parameters at start-up
1178
1179 10.2.3.2 Password

1180 The password mechanism is only required for the FS-Master. It shall consider the roles of the
1181 upper level FSCP system and inherit permissions from there if possible. Due to increased
1182 security requirements (IEC 62443), the mechanism shall be based on encryption methods. For
1183 details see Annex A.2.10.
1184 Dedicated Tools can have additional password mechanisms independent from the FS-Master.
1185 10.2.3.3 FSP parameter block – authenticity

1186 FSP authenticity parameters are specified in Annex A.2.1. The authenticity activities for an
1187 FSCP-System are described in 10.2.3.1 including the CRC signature calculation.
1188 For stand-alone FS-Masters the entry of unique and unambiguous values per FS-Master is
1189 required per machine or production center, if there is a possibility to misconnect FS-Device
1190 amongst different FS-Masters. FS-Devices will accept and store FSP authenticity values only
1191 when FSP_TechParCRC = "0".
1192 10.2.3.4 FSP parameter block – protocol

1193 FSP protocol parameters are specified in Annex A.1. Manufacturer/vendor pre-sets values
1194 and defines ranges within the IODD for protocol version and mode, port mode, watchdog, and
1195 TechParCRC.
1196 Manufacturer/vendor shall determine the pre-set value for the watchdog timer considering the
1197 FS-Device response time at the indicated transmission rate. The FS-Master Tool can
1198 calculate and suggest a value based on the performance data of the used FS-Master and on
1199 the pre-set value from the IODD.
1200 The FS-Master Tool calculates the CRC signature across the FSP protocol parameter record.
1201 10.2.3.5 FS I/O structure description

1202 With the help of this information, the mapping process within the FSCP gateway can be
1203 controlled or monitored (see 11.7.7 and A.2.9).
1204 The FS-Device can check the validity of the safety PDin/PDout structure via the
1205 FSP_IO_StructCRC signature within the FSP parameter record.
1206 10.3 Process Data Exchange (PDE)

1207 Safety Layer Manager is responsible to set-up the safety-related Process Data depending on
1208 FS_PortModes (see 10.2.2). It can be either a Safety PDU or single bits (one from OSSDe
1209 and another one for the qualifier). Process Data Exchange takes over or passes SR Process
1210 Data (see 11.4.3 Safety PDU) from/to the Safety Layer Manager.
1211 10.4 Data Storage (DS)

1212 In [1], Data Storage has been specified separately for Master and Device. In practice it turned
1213 out to be straighter forward to specify the mechanism as a whole in one place. It can be found
1214 in 9.4 in this document.
1215
1216 11 Safety communication layer (SCL)

1217 11.1 Functional requirements
1218 The functional requirements for safety communication are laid down in [11]. Main application
1219 area is "safety for machinery". Usually this means operational stop of a machine until clearan-
1220 ce or repair and restart only after an operator acknowledgement. Primarily relevant are IEC
1221 62061 and ISO 13849.
1222 Other major requirements are suitability for up to SIL3/PLe safety functions, port specific
1223 passivation, and parameterization using dedicated tools. Safety measures and residual error
1224 rates for authenticity, timeliness, and data integrity of safety messages (safety PDUs) shall be
1225 compliant with IEC 61784-3, Edition 3.
1226 11.2 Communication faults and safety measures

1227 The point-to-point communication basis of IO-Link allows for a very lean protocol type and a
1228 hardware independent safety communication layer stack with a small memory footprint. Table
1229 16 shows the communication errors to be considered and the chosen safety measures
1230 • (Sequence) counter / inverted counter;

1231 • Watchdog timer and receipt messages;
1232 • Connection validation at commissioning, start-up, and repair; and
1233 • Cyclic redundancy check for data integrity.
1234 Table 16 – Communication errors and safety measures
Protocol safety measures
Counter/Inverted Timeout with Connection Cyclic redundancy

Communication error counter receipt validation a check (CRC)
Corruption – – – X
Unintended repetition X X – –
Incorrect sequence X – – –
Loss X X – –
Unacceptable delay – X – –
Insertion X – – –
Masquerade – – – X
Addressing – – X –
Loop-back of messages X – – –
a Similar procedure as with functional safety digital input modules possible due to point-to-point
communication
1235 It is assumed, that there are no storing elements within the IO-Link communication path
1236 between FS-Master and FS-Device. Thus, a two bit counter is sufficient as a safety measure.
1237 A value 0b000 of this counter indicates a start or reset position of this counter. In cyclic mode
1238 it counts up to 0b111 and returns to 0b001.
1239 The message send and receive concept of IO-Link allows for a simple watchdog timer and
1240 message receipt safety measure concept corresponding to the "de-energize to trip" principle.
1241 It is assumed that an FS-Master is the owner of a functional safety connection ID of the upper
1242 level FSCP communication system similar to an FS-DI-Module within a remote I/O. A
1243 customer is required to perform a validation procedure, whenever a change occurred with the
1244 connected safety devices. IO-Link Safety relies on such a concept. Additionally, due to the
1245 standard "data storage" mechanism of IO-Link and the functional safety nature of the FS-
1246 Master, it is possible to provide a more convenient mechanism.
1247 A CRC signature is used for the data integrity check of transmitted safety PDUs. Two options
1248 can be configured. A 16 bit CRC signature for safety I/O data up to 4 octets or a 32 bit CRC
1249 signature for safety IO data up to 26 octets can be chosen.
1250 11.3 SCL services

1251 11.3.1 Positioning of safety communication layers (SCL)
1252 Figure 37 shows the positioning of the IO-Link Safety Communication Layer (SCL).
PLC / Host
FS-PLC / FS-Host
Designs and implementations

Fieldbus according to IEC 61508, for example
redundant microcontrollers
FS-Device
FS-Master
Sensor / Actuator
FSCP-Gateway FS-Technology
(FS-Master) Tool:
- configuration, PDout + safety code
- parameterization, IO-Link SCL IO-Link SCL
- diagnosis, for FS-Master per Port for FS-Device
- identification &
PDin + safety code
maintenance
IO-Link communication IO-Link communication
IO-Link point to point communication with sufficient availability

1253
1254 Figure 37 – Positioning of the IO-Link Safety Communication Layer (SCL)
1255 For each port with a connected FS-Device an instance of the IO-Link SCL is required. The
1256 SCLs are exchanging safety PDUs consisting of output Process Data (PDout) together with
1257 safety code to the FS-Device and input Process Data (PDin) together with safety code from
1258 the FS-Device. The SCLs are using standard IO-Link communication as a "black channel".
1259 Sufficient availability through for example correct installations, low-noise power supplies, and
1260 low interferences are preconditions for this "black channel" to avoid so-called nuisance trips.
1261 Nuisance trips cause production stops and subsequently may cause management to remove
1262 safety equipment.
1263 This document does not specify implementation related safety measures such as redundant
1264 microcontrollers, RAM testing, etc. It is the responsibility of the manufacturer/vendor to take
1265 appropriate measures against component failures or errors according to IEC 61508.
1266 11.3.2 FS-Master SCL services

1267 IO-Link safety applications include (but are not limited to) connections to upper level FSCP
1268 fieldbus systems. FSCPs usually provide also safety codes and control/monitoring services
1269 (signals).
1270 Figure 38 shows the FS-Master Safety Communication Layer signals (services) depicted by
1271 arrows in the upper part of the figure. For each FSCP to be connected to, a mapping or
1272 emulation of corresponding SCL services is required.
1273 A service name carries either an extension "_C" (Control), if it controls the safety
1274 communication activities or an extension "_S" (Status), if it is reporting on the activities.
1275 Some of the service names correspond to the signal names of the Control Byte or Status Byte
1276 (see lower part of the figure and 11.4.5). That means they are correlated, but there is some
1277 control logic of the SCL in between. This control logic is time discrete and not continuous
1278 even if it is depicted as logic OR ("≥") box. Definitive are the state charts and the state
1279 transition tables of the SCL (see 11.5.2).
FSCP-Gateway Qualifier handler
PDin_M
ChFAckReq_S
FAULTS_S
ChFAck_C
setSD_C
SDset_S
PDout_M
FS-Master Time Base

SCL ≥1
Startup
states Watchdog
1 to 3 FAULTS timer
SDset_S
FAULTS
setSD_C ChFAck_C_e
≥1 MTimeout
MCommErr
SDin SDout
DTimeout CRC
MCount & Check
DCommErr in/out
PDin
ChFAckReq
DCommErr
DCount2_i
DCount1_i
DCount0_i
DTimeout
MCount0
MCount2
MCount1
setSD
SDset
Safety PDout
PDU
CB1 SB3 CB0 CB7 CB6 CB5 SB7 SB6 SB5 SB1 SB0
FS-PD CRC
Control&MCnt / Status&DCnt Byte
IO-Link communication interface

1280
1281 Figure 38 – FS-Master Safety Communication Layer services
1282 The following services in Table 17 shall be available to the FSCP gateway or to a programmer
1283 of an FS-Master system.
1284 Table 17 – SCL services of FS-Master
Service/signal Definition
PDin_M, PDout_M These services carry the actual Process Data values, both SDin (all bits "0") and SDout
(all bits "0") in case of safe state or the real process values from or to the FS-Device.
SDin, SDout These services carry Process Data values all zero.
setSD_C In case of emergency, safety control programs usually set output Process Data
(PDout_M) for an actuator to "0". However, in some cases, for example burner
ventilators, shut down may not be a safe state. This service, if set to "1", is additional
information allowing an FS-Device to establish a safe state no matter what the values of
Process Data are.
Independent from PDout_M, this service causes the SCL to send SDout values to the
FS-Device and to send SDin to the FSCP gateway (PDin_M) via SDset_S.
SDset_S This service, if set to "1", causes the qualifier handler to set the qualifier bit for the
Process Data of the connected FS-Device (see 11.10.4). In addition, it causes the SCL
to send SDin to the FSCP gateway (PDin_M).
ChFAckReq_S The FS-Master SCL sets this service to "1" in case of FAULTS or FS-Master timeouts. It
shall be propagated via FSCP and indicated to the operator.
ChFAck_C After check-up and/or repair, the operator is requested to acknowledge a
"ChFAckReq_S" service via a "1". This is a precondition for the SCL to resume regular
operation after 3 transmission cycles with SDin and SDout values.
The SCL-internal signal ChFAck_C_e is used for actual evaluation instead of the
ChFAck_C service. It is only set, whenever the ChFAck_C service changed value (edge-
sensitive) to avoid any continuously pressed acknowledgment button.
Fault_S Any communication error (counter mismatch or CRC signature error) and/or timeouts
cause the qualifier handler to set the qualifier bit for the Process Data of the connected
FS-Device (see 11.10.4).
1285
1286 The lower part of the figure shows a combined input and output safety PDU specified in
1287 11.4.3 and 11.4.5.
1288 11.3.3 FS-Device SCL services

1289 Figure 39 shows the FS-Device Safety Communication Layer services depicted by arrows in
1290 the upper part of the figure.
NSR part Specific FS-Device technology Safety-related part (SR part)
Diag- PDout_D
Indication of new
ChFAckReq_DC
nosis "Time
DCount value
Tick"
Read FSP-
SCL_Fault
setSD_DC
Parameter
SDset_DS
FSP-
Para- PDin_D
meter
Diagnosis SCL_Fault
Time
FSP SDset_p Base
FSP-Parameter, diagnosis
(SDcycles) CRC
SDin SDout
out
>=1 CRC or Counter CRC

Start-up >=1
error in
states
20 to 22
Use_SDout Watchdog
Check & DCount_i
FS-Device timer
SCL
PDout
CRC signature
ChFAckReq
DCommErr
DCount2_i
DCount1_i
DCount0_i
DTimeout
MCount2
MCount1
MCount0
SDset
setSD
SPDU PDin
CB1 SB2 CB0 CB7 CB6 CB5 SB7 SB6 SB5 SB1 SB0
FS Process Data (PD) CRC
Control&MCnt / Status&DCnt Byte
IO-Link communication interface

1291
1292 Figure 39 – FS-Device Safety Communication Layer services
1293 A service name carries either an extension "_DC" (Device Control) if it controls the FS-Device
1294 technology or an extension "_DS" (Device Status) if it is reporting its status.
1295 Some of the service names correspond to the signal names of the Control Byte or Status Byte
1296 (see lower part of the figure and 11.4.5). That means they are correlated, but there is some
1297 control logic of the SCL in between. This control logic is time discrete and not continuous
1298 even if it is depicted as logic OR ("≥") box. Definitive are the state charts and the state
1299 transition tables of the SCL (see 11.5.3).
1300 The following services in Table 18 shall be available to the safety-related part of the FS-
1301 Device technology. Some services are non-safety-related and shall be available to the non-
1302 safety-related part of the FS-Device.
1303 Table 18 – SCL services of FS-Device
PDin_D, PDout_D These services carry the actual Process Data values. Real process values from the FS-
Device and SDout (all bits "0") in case of safe state or the real process values to the FS-
Device.
SDin, SDout These services carry Process Data values all zero. Signal Use_SD indicates the usage
of Process Data all zero.
setSD_DC In case of emergency, safety control programs usually set output Process Data (PDout)
for an actuator to "0". However, in some cases, for example burner ventilators, shut
down may not be a safe state. This service, if set to "1", is additional information
allowing an FS-Device to establish a safe state no matter what the values of Process
Data are.
Independent from PDout, this service causes the SCL to send SDout values to the FS-
Device.
SDset_DS This service, if set to "1", indicates that the FS-Device either reacts on a setSD_DC =
"1" when the safe state is established or has been forced to establish safe state due to
error or failure and delivers input Process Data values "0" (PDin_D).
ChFAckReq_DC This service, if set to "1", indicates a pending operator acknowledgment. This signal is
not safety-related and can be used to control an indicator, for example LED (light
emitting diode).
Time tick The SCL can be designed totally hardware independent, if a periodic service call
controls a time base inside the SCL.
Indication of new Short demands of FS-Devices may not trip a safety function due to its chain of
DCount value independent communication cycles across the network. Therefore, a demand shall last
for at least two SCL cycles. This service provides the necessary information to
implement the demand extension if required.
SCL_Fault This service provides faults (errors) of the SCL software.
Read_FSP_Parameter This service allows the FS-Device technology for reading the current FSP (protocol)
parameter
Non-safety-related services:
FSP_Parameter The FS-Master transmits the FSP parameter record (block) at each start-up during
PREOPERATE to the FS-Device. These parameters are propagated to the SCL using
this service.
Diagnosis SCL diagnosis information can be propagated to the IO-Link Event system using this
service.
1304
1305 The lower part of Figure 39 shows a combined input and output safety PDU specified in
1306 11.4.3 and 11.4.5.
1307 11.4 SCL protocol

1308 11.4.1 Protocol phases to consider
1309 Figure 40 shows the principle protocol phases to consider for the design according IEC
1310 61784-3.
Start
Initialization Fault
Warm start
Tolerated
Correct IO-Link Safety operation
error (optional)
1311
1312 Figure 40 – Protocol phases to consider
1313 The principle protocol phases and the corresponding requirements are listed in Table 19.
1314
1315 Table 19 – Protocol phases to consider
Phase Activities Requirements
Initialization Establish communication, - Actuator shall be de-energized

transfer FSP parameter to FS- - SDout values shall be used during the first 3 SCL
Device, SD cycles communication cycles
Setup or change Commissioning, FST parame- - As long as the FSP_TechParCRC is set to "0", cyclic
ter backup data exchange of PD values is enabled.
Phase Activities Requirements
Operation Process Data exchange, - It is the responsibility of the FS-Device technology to

power-down of FS-Device detect undervoltages and to set SD values.
Restart after Timeout, operator acknowledg- - Operator acknowledgment is required prior to a restart
transition from fault ment - MCounter reset (resynchronization)
- SDout values shall be used during the first 3 SCL
communication cycles
Warm start after CRC or counter error, operator - Operator acknowledgment is required prior to a restart
transition from fault acknowledgment - SCL communication is not reset
- SDout values shall be used during the first 3 SCL
communication cycles
Shutdown Contact bouncing, EMC - It is the responsibility of the FS-Device technology to
voltage dips/changes detect undervoltages and to set SD values.
1316
1317 11.4.2 FS-Device faults

1318 The SCL protocol copes with faults occurring during transmission of safety PDUs such as
1319 CRC errors or timeouts. It is the responsibility of the designer of the FS-Device to cope with
1320 FS-Device faults and to make sure that the necessary functional safety actions will take place,
1321 for example setting of safety Process Data and the SDset_DS service.
1322 11.4.3 Safety PDU (SPDU)

1323 Figure 41 shows the structure of SPDUs of the FS-Master and FS-Device together with
1324 standard input and output data. The design follows the concept of explicit transmission of the
1325 safety measures for timeliness and authenticity according to IEC 61784-3 in contrast to the
1326 implicit transmission via inclusion in the overall CRC signature calculation.
From FS-Master:
Output PD CRC signature Control&MCnt FS-PDout
Signature across
Including 0 to 4 octets, or
FS-Output data
3 bit counter 0 to 26 octets
and Control & counting
32 to 0 octets 2/4 octets 1 octet 4/26 octets
From FS-Device:
FS-PDin Status&DCnt CRC signature Input PD
Including Signature across

0 to 4 octets, or FS-Input data
3 bit counter
0 to 26 octets and Status & counting mirror
inverted
4/26 octets 1 octet 2/4 octets 32 to 0 octets

1327
1328 Figure 41 – Safety PDUs of FS-Master and FS-Device
1329 The timeliness measure is represented by a 3 bit counter within the protocol management
1330 octets (see 11.4.5).
1331 Inclusion of authenticity code in the cyclic checking is not necessary due to the point to point
1332 communication of IO-Link. This check is performed during commissioning and at start-up.
1333 The design follows also the "de-energize to trip principle". In case of a timeout, or a CRC
1334 error, or a counter error, the associated qualifier bit will be set. It will be only released after an
1335 explicit operator acknowledgment on the FS-Master side.
1336 After a CRC error a warm start is possible.
1337 11.4.4 FS-Input and FS-Output data

1338 The maximum possible size of the FS-Input and FS-Output data reaches from 0 to 26 octets
1339 depending on the amount of required standard IO-Link data. See 11.4.6 for optimization
1340 issues and trade-offs.
1341 NOTE Currently the safety trailer consists of only 3 or 5 octets and theoretically 28 octets could be available.
1342 However, since not all design verification steps are passed, a reserve of 1 octet is planned.
1343 The possible data types are listed in Table 23.
1344 11.4.5 Status and control

1345 One octet is used in both transmission directions for the protocol flow of IO-Link Safety.
1346 Table 20 shows the signals to control the protocol layer of an FS-Device and a counter value
1347 for the timeliness check together with a local watchdog timer adjusted through the
1348 "FSP_Watchdog" parameter (see A.2.6).
1349 Table 20 – Control and counting (Control&MCnt)
CB7 CB6 CB5 CB4 CB3 CB2 CB1 CB0

Sequence Sequence Sequence Reserved Reserved Reserved Activate safe Channel fault
counter, counter, counter, ("0") ("0") ("0") state acknowledge
bit 2 bit 1 bit 0 request
(indication)
MCount2 MCount1 MCount0 – – – SetSD ChFAckReq
1350
1351 Table 21 shows the feedback of the protocol layer of an FS-Device and the inverted counter
1352 value for the timeliness check. The counter values are inverted to prevent from loop-back
1353 errors.
1354 Table 21 – Status and counting mirror (Status&DCnt)
SB7 SB6 SB5 SB4 SB3 SB2 SB1 SB0

Sequence Sequence Sequence Reserved Reserved Safe state Communication Communi-
counter, counter, counter, ("0") ("0") activated error: cation fault:
bit 2; bit 1; bit 0; CRC or counter Timeout
inverted inverted inverted incorrect
DCount2_i DCount1_i DCount0_i – – SDset DCommErr DTimeout
1355
1356 Table 22 shows the values of MCount and DCount_i during protocol operation.
1357 Table 22 – MCount and DCount_i values
Phase MCount DCount_i

Dec Bin Dec Bin
Initial or after 0 000 7 111

timeout
Cyclic 1 001 6 110
2 010 5 101
3 011 4 100
4 100 3 011
5 101 2 010
6 110 1 001
7 111 0 000
1358
1359 11.4.6 CRC signature

1360 For the design of the CRC mechanism and the calculation of the residual error probability/rate
1361 several parameters and assumptions are required:
1362 • Explicit transmission of safety measures as opposed to implicit transmission. In this case,
1363 formulas are available within IEC 61784-3, Edition 3.
1364 • The sampling rate of safety PDUs is assumed to be a maximum of 1000 sampled safety
1365 PDUs per second.
1366 • The monitoring times for errors in safety PDUs are listed in Table 30. Any detected CRC
1367 error within the safety communication layer shall trip the corresponding safety function
1368 (safe state). During the monitoring time only one nuisance trip is permitted. Maintenance
1369 is required.
1370 • The generator polynomials in use shall be proven to be proper within the SPDU range.
1371 • The seed value to be used for the CRC signature calculation is "1" (see D.3.6).
1372 • In case the result of the CRC signature calculation leads to a "0", a "1" shall be sent and
1373 evaluated at the receiver side correspondingly.
1374 • The assumed bit error probability for calculations is 10 -2 .
1375 Figure 42 shows the so-called 1 % share rule of the IEC 61784-3. For IO-Link Safety it
1376 means, the residual error rate of an IO-Link Safety logical connection shall not exceed 1 % of
1377 the average probability of a dangerous failure (PFH) of that safety function with the highest
1378 SIL the safety communication is designed for, which is SIL3. This value is 10 -9 /h.
Safety Function
Logical Logical
connection Programmable connection
FS- FS-
electronic
Master Master
system
≤1% ≤1%
FS-Device FS-Device
1379
1380 Figure 42 – The 1 % share rule of IEC 61784-3
1381 Calculations under the above conditions have shown the following possibilities (see Annex D):
1382 – For a CRC16 proper polynomial (0x4EAB) 4 octets of process data (safety PDU length = 7
1383 octets);
1384 – For a CRC32 proper polynomial (0xF4ACFB13) 26 octets of process data (safety PDU
1385 length = 32 octets).
1386 Thus, support of two variants is provided: CRC-16 with up to 4 octets of safety I/O data and
1387 CRC-32 with up to 26 octets.
1388 11.4.7 Data types for IO-Link Safety

1389 11.4.7.1 General
1390 The cyclically exchanged functional safety data structures between FS-Device and FS-Master
1391 comprise FS process I/O data and the IO-Link Safety protocol trailer. They are transmitted in
1392 Safety PDUs.
1393 Acyclically exchanged functional safety data structures are transmitted in IO-Link On-request
1394 Data (OD) containers either from a dedicated tool or from a user program within an FS-PLC.
1395 In this case additional securing mechanisms (e.g. CRC signature) are required at each and
1396 every transfer or after a parameter block.
1397 11.4.7.2 FS process I/O data (PDin and PDout)

1398 For the FS process I/O data a well-defined set of data types and a corresponding description
1399 is defined for both FS-Device and FS-Master for correct processing and mapping to the
1400 upper-level FSCPs. Table 23 lists the three permitted data types (see Annex C).
1401 Table 23 – FS process I/O data types
Data type Coding Length See [1] Device example
BooleanT/bit BooleanT ("packed form" for efficien- 1 bit Clause E.2.2; Table Proximity switch
cy, no WORD structures); assignment E.22 and Figure E.8
of signal names to bits is possible.
IntegerT(16) IntegerT (enumerated or signed) 2 octets Clause E.2.4; Table Protection fields of
E.4, E.7 and Figure laser scanner
E.2
IntegerT(32) IntegerT (enumerated or signed) 4 octets Clause E.2.4; Table Encoder or length
E.4, E.6, and Figure measurement (≈ ± 2
E.2 km, resolution 1 µm)
1402
1403 11.4.7.3 Qualifier

1404 FS-Devices normally do not require qualifiers (see 11.10.2). The qualifier bits are configured
1405 together with the Process Data (or Safe Data = SD) during the mapping to the upper level
1406 FSCP system. The data structures depend on the rules of these FSCP systems.
1407 In case of FS-Terminals (see 11.10.3) the rules in Table 24 for the layout of binary and digital
1408 data and their qualifier bits apply.
1409 Table 24 – Rules for the layout of values and qualifiers
No. Rule Remark
1 Only Boolean (DI, DO) and IntegerT(16) or IntegerT(32) (AI, AO)

data types shall be used. Any value shall be assigned to one of
these categories.
2 Boolean values precede Integer values.
3 IntegerT(16) precedes IntegerT(32) values
4 Values precede qualifier in an octet-wise manner
5 Qualifiers follow directly input values. In case of no input values
only the qualifiers for output values are placed.
6 Qualifier for input values precede qualifier for output values
7 Qualifiers for each category (DI, DO, AI, AO) are packed
separately in an octet-wise manner.
8 If data types are missing the remaining data types catch up.
1410 Table 25 shows the ranking of values and qualifiers.
1411 Table 25 – Order of values and qualifier
Order To FS-Master To FS-Device
1 Value DI Value DO
2 Value AI Value AO
3 Qualifier DI –
4 Qualifier AI –
5 Qualifier DO –
6 Qualifier AO –
1412
1413 11.4.7.4 IO-Link Safety protocol trailer

1414 The data types for the protocol trailer ("safety code") are specified in Annex C.5.
1415 11.4.7.5 FSP and FST parameter

1416 No particular data type definitions are required.
1417 11.5 SCL behavior

1418 11.5.1 General
1419 The state machines for the FS-Master and the FS-Device safety communication layer are
1420 designed using the chosen safety measures in Table 16 and the protocol signals in 11.4.5.
1421 11.5.2 SCL state machine of the FS-Master

1422 Figure 43 shows the FS-Master state machine for wired IO-Link point-to point communication.
Configuration OK Parameter OK Authentication OK

FS-Master ChFAck_C_e = 0 ChFAckReq_S = 0 ChFAckReq = 0
Initial values = 0
/Initialization
T1
PrepareSPDU_6 PrepareSPDU_1
tm(MTime)/
T8
Send_SPDU/ Send_SPDU/
T9 T2
WaitOnResponse_2
WaitOnResponse_7
[received and not

tm(MTime)/ [received and [received]/
old SPDU]/
T14 expected SPDU]/ WaitOnResponse_5 T3
T6
T10
CheckSPDU_8
Send_SPDU/ CheckSPDU_3
do CRC_check T5
do Counter_check do CRC_check
do Counter_check
[not FAULTs and PrepareSPDU_4
(not ChFAck_C or
[not FAULTS]/ [FAULTS]/
not ChFAck_C_e)]/
T4 T7
T13 [not FAULTS and
ChFAck_C and
ChFAck_C_e]/
[FAULTS]/
T11
T12
1423
1424 Figure 43 – SCL state machine of the FS-Master
1425 The terms used in Figure 43 are defined in Table 26.
1426 Table 26 – Definition of terms used in SCL state machine of the FS-Master
Term Definition
ChFAck_C Operator acknowledgment for the safety function via the FS-Gateway
FAULTS MTimeout: FS-Master timeout when waiting on an FS-Device SPDU response, or
MCommErr: FS-Master detects a corrupted FS-Device SPDU response (incl. counter error), or
DTimeout: FS-Device reported a timeout of its SCL via Status&DCnt Byte, or
DCommErr: FS-Device reported a CRC (incl. counter error) by its SCL via Status&DCnt Byte
1427 Table 27 – FS-Master SCL states and transitions
Initialization Initial state of the FS-Master SCL instance upon power-on (one per port).
1 PrepareSPDU Preparation of a (regular) SPDU for the FS-Device. Send SPDU when prepared.
2 WaitOnResponse SCL is waiting on SPDU from FS-Device.
3 CheckSPDU Check received SPDU for not FAULTS ( T4). In case of FAULTS: errors within the
Status&DCnt Byte (DCommErr, DTimeout, SDset)  T7
4 PrepareSPDU Preparation of a (regular) SPDU for the FS-Device. Send SPDU when prepared.
5 WaitOnResponse SCL is waiting on next SPDU from FS-Device not carrying the previous DCount_i.
6 PrepareSPDU Preparation of an (exceptional) SPDU for the FS-Device (due to MTimeout, missing OpAck,
or FAULTS).
7 WaitOnResponse SCL is waiting on next SPDU from FS-Device not carrying the previous DCount_i. When
received  T10, after MTimeout  T14.
8 CheckSPDU Check received SPDU for a CRC error (MCommErr) and for potential FS-Device faults
within the Status&DCnt Byte (DTimeout, DCommErr). Once a fault occurred, no automatic
restart of a safety function is permitted unless an operator acknowledgement signal
(ChFAck_C) arrived (see Figure 38). Hint: A delay time may be required avoiding the
impact of an occasional system shutdown.
1428
TRAN- SOURCE TARGET ACTION
SITION STATE STATE
T1 0 1 use SD, setSD =1, SDset_S =1

MCount = 0
T2 1 2 –
T3 2 3 –
T4 3 4 MCount = MCount + 1
if MCount = 8
then MCount = 1
if SDset =1 or setSD_C =1
then use SDin, SDset_S =1
else use PDin, SDset_S =0
if setSD_C =1
then use SDout, setSD =1
else use PDout, setSD =0
T5 4 5 restart MTimer
T6 5 3 –
MCount = MCount + 1
if MCount = 8
then MCount = 1

MCount = 0
T9 6 7 restart MTimer
T10 7 8 –
T11 8 4 ChFAckReq =0, ChFAckReq_S =0, ChFAck_C_e =0,
MCount = MCount + 1
if MCount = 8
then MCount = 1
if SDset =1 or setSD_C =1
then use SDin, SDset_S =1
else use PDin, SDset_S =0
if setSD_C =1
then use SDout, setSD =1
else use PDout, setSD =0

use SD, setSD =1, SDset_S =1
MCount = MCount + 1
if MCount = 8
then MCount = 1
T13 8 6 ChFAckReq =1, ChFAckReq_S =1, /*set qualifier/acknowledgment request*/

if ChFAck_C = 0
then ChFAck_C_e =1
MCount = MCount + 1
if MCount = 8
then MCount = 1
MCount = 0
1429
MTimer Timer This timer checks the arrival of the next valid SPDU from the FS-Device in
time. The FS-Master Tool is responsible to define this watchdog time. Value
range is 0 … 65 535 ms.
ChFAck_C_e Flag By means of this auxiliary variable (bit) it is ensured that the safe state will be
left only after a signal change of ChFAck_C from 0  1 (edge). Without this
mechanism an operator could overrule safe states by permanently actuating
the ChFAck_C signal.
FAULTS Flags Permanent storage of the following errors or failures can be omitted within the
FS-Master, if it can be assumed that the upper level FSCP system prevents
from automatic restart of safety functions (no FS-Device persistence):
- MCommErr
- MTimeout
- DCommErr, including counter error (Status&DCnt Bit 1)
- DTimeout (Status&DCnt Bit 0)
Expected SPDU Guard Mirrored inverted counter (DCount_i = inverted MCount)
Not old SPDU Guard Counter value ≠ value of previous SPDU
do CRC_check Activity SCL calculates CRC signature across received SPDU while signature value =
"0" and compares with received CRC signature
do Counter_check Activity SCL checks whether DCount carries an expected value (mirror)
NOTE Variables within ACTIONs are defined in 11.3
1430
1431 11.5.3 SCL state machine of the FS-Device

1432 Figure 44 shows the corresponding FS-Device state machine.
Startup test OK Configuration OK Parameter OK

Initial values = 0 SDcycles = 3 DTimeout =1 /Initialization
TimeoutCount = 0 CommErrCount = 0 use SDin, SDout
Authentication OK
SystemStart_20
[System start OK]/

PrepareResponse_25 T20
tm(DTime)/
T31 WaitOnSPDU_21
Send_SPDU/
T26
[received]/
WaitOnSPDU_26 T21
[received and
not old SPDU]/
T24
tm(DTime)/ [received and not old
T30 SPDU]/ WaitOnSPDU_24
T27 CheckSPDU_22
do CRC_check
CheckSPDU_27 do Count_check
Send_SPDU/
do CRC_check T23
do Count_check
[No CommErr]/ [CommErr]/
T22 T25
[CommErr or [No CommErr and
SDcycles > 0]/ SDcycles = 0]/ PrepareResponse_23
T29 T28
1433
1434 Figure 44 – SCL state machine of the FS-Device
1435 The terms used in Figure 44 are defined in Table 28.
1436 Table 28 – Definition of terms used in SCL state machine of the FS-Device
Term Definition
CommErr The SCL within the FS-Device detected a CRC or counter error in the received SPDU
Term Definition
CommErrCount See INTERNAL ITEM in Table 29

SDcycles See INTERNAL ITEM in Table 29
DTimeout FSP_WatchdogTime expired
TimeoutCount See INTERNAL ITEM in Table 29
1437
1438 Table 29 – FS-Device SCL states and transitions
Initialization Initialization of the FS-Device upon power-on. Upon power-on, the FS-Device (actuator)
sets the PDout to "0". Upon power-on the FS-Device (sensor) is sending "0".
20 SystemStart Immediately after FSP parameterization the FS-Device sets PDout to SDout values.
Immediately after FSP parameterization it is sending Process Data (PD).
21 WaitOnSPDU SCL is waiting on next SPDU from FS-Master.
22 CheckSPDU Check received SPDU from FS-Master for CRC errors; set ChFAckReq_DC = ChFAckReq.
When guard "No CommErr" = true  T22. When guard "CommErr " = true  T25
23 PrepareResponse Preparation of (regular) SPDU response for the FS-Master (response message)
24 WaitOnSPDU SCL is waiting on next (regular) SPDU from FS-Master not carrying the previous MCount.
After FSP_WatchdogTime expired  T27. When SPDU received and guard
"MCounter_incremented" = true  T24 (regular cycle)
25 PrepareResponse Preparation of (exceptional) SPDU response for the FS-Master (due to DTimeout or
DCommErr = error report bits in Status&DCnt Byte)
26 WaitOnSPDU SCL is waiting on next SPDU from FS-Master not carrying the previous MCount. After
FSP_WatchdogTime expired  T30. When SPDU received and guard
"MCounter_incremented" = true  T27
27 CheckSPDU Check received SPDU from FS-Master for CRC errors; set ChFAckReq_DC = ChFAckReq.
When guard "No CommErr and SDcycles >=1" = true  T28. When guard "CommErr or
SDcycles <1" = true  T29
1439
SITION STATE STATE
T20 20 21 –
T21 21 22 –
T22 22 23 use PDin_D,
DCommErr = 0, /*Status&DCnt, Bit 1*/
DTimeout = 0, /*Status&DCnt, Bit 0*/
DCount_i = MCount_inv,
restart DTimer
if SDcycles <> 0
then
use SDout, setSD_DC=1, SDset =1, /*during SDcycles: SDset_p =1*/
SDcycles = SDcycles - 1
else
use PDout, setSD_DC=0, SDset = 0
if setSD =1 /*use_SD =1*/
then
use SDout, setSD_DC=1,
T23 23 24 if SDset_DS = 1 /* FS-Device fault*/
then SDset = 1
T24 24 22 –
use SDout, SDset = 1,
DCommErr =1, /*Status&DCnt, Bit 1*/
CommErrCount = 1,
SDcycles = 3,
restart DTimer
T26 25 26 –

SITION STATE STATE
T27 26 27 –
use SDout, setSD_DC=0, SDset = 0,
DCommErr =0, /*Status&DCnt, Bit 1*/
DTimeout =0, /*Status&DCnt, Bit 0*/
restart DTimer,
use SDout, setSD_DC=1, SDset = 1,
restart DTimer
if CommErr
then
CommErrCount = 1,
SDcycles = 3,
else
SDcycles = SDcycles -1
if CommErrCount = 1
then
CommErrCount = 0
else DCommErr = 0 /*Status&DCnt, Bit 1*/
if TimeoutCount = 1
then
DTimeout = 1, /*Status&DCnt, Bit 0*/
TimeoutCount = 0
else DTimeout = 0 /*Status&DCnt, Bit 0*/

use SDout, setSD_DC=1, SDset =1,
TimeoutCount =1,
SDcycles = 3,
restart DTimer,
DCount_i = MCount_inv
use SDout, setSD_DC=1, SDset =1,
TimeoutCount =1,
SDcycles = 3,
restart DTimer,
DCount_i = MCount_inv
1440
INTERNAL ITEM TYPE DEFINITION
MCount_inv Variable Inverse value of current MCount value

SDcycles Counter This decremental counter is used to cause the FS-Device setting SDout and
SDset for at least 3 cycles during start-up and after a fault. Value range is 3 to
0.
CommErrCount Counter This decremental counter is used to guarantee the bit "DCommErr" within the
Status&DCnt Byte is being set at least for 1 cycle or for a maximum of 2
cycles. Value range is 1 to 0.
TimeoutCount Counter This decremental counter is used to guarantee the bit "DTimeout" within the
Status&DCnt Byte is being set at least for 1 cycle or for a maximum of 2
cycles. Value range is 1 to 0.
do CRC_check Activity SCL calculates CRC signature across received SPDU while signature value =
"0" and compares with received CRC signature
do Counter_check Activity SCL checks whether MCount carries either "0" or an expected subsequent
value
NOTE Variables within ACTIONs are defined in 11.3
1441
1442 It is very unlikely for an FS-Device to receive SPDUs with all octets "0". The SCL within the
1443 FS-Device shall ignore such an SPDU. Normally, at least the CRC signature will be "1" if
1444 Process data and Control Byte are "0" according to the rules in 11.4.6.
1445 11.5.4 Sequence charts for several use cases

1446 11.5.4.1 FS-Master and FS-Device both with power ON
1447 Figure 45 shows the sequence chart of a regular start-up of both FS-Master and FS-Device.
Master Master SCL Device SCL

PREOPERATE (Power ON) (Power ON)
FSP_Parameter()
........ 20 SDout
SDin
M_SPDU(SDout, MCount=0, setSD=1, ChFAckReq=0, CRC)
1 21
SDout
D_SPDU(PDin, DCount_i=7, SDset=1, DCommErr=0, DTimeout=0,CRC) SDcycles = 3
SDin 3 23
M_SPDU(PDout, MCount=1, setSD=0, ChFAckReq=0, CRC)

4 24
SDout
D_SPDU(PDin, DCount_i=6, SDset=1, DCommErr=0, DTimeout=0, CRC) SDcycles = 2
SDin 3 23

4 24
SDout
SDin 3 23

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23
FS-Device switches from Safe Data (SD) to Process Data (PD) after
three SPDU cycles (SDset=1 to SDset=0). MCount starts with 0 and
wraps over to 1.
1448
1449 Figure 45 – FS-Master and FS-Device both with power ON
1450 Upon power-on both FS-Master and FS-Device are providing SDin (PDin = "0") and SDout
1451 (PDout = "0") respectively. Both keep these values for 3 communication cycles (SDcycles)
1452 before switching to the regular mode, where only the MCounter and DCounter values are
1453 changing.
1454 11.5.4.2 FS-Master with power OFF  ON

1455 Figure 46 shows the sequence chart of regular operation while FS-Master has been switched
1456 OFF and ON again.

PREOPERATE (Power OFF (Power ON)
--> ON)
D_SPDU(PDin, DCount_i=4, SDset=1, DCommErr=0, DTimeout=1, CRC)

25 SDout
........ 26
Power ON
Establish
FSP_Parameter() communication
........ 20 SDout
SDin
1 21
SDout
SDin 3 23 SDcycles = 3

4 24
SDout
SDin 3 23

4 24
SDout
SDin 3 23

4 24
PDout
PDin 3 23 SDcycles = 0

4 24
PDout
PDin 3 23

4 24
PDout
PDin 3 23
FS-Master as part of the FSCP device was switched OFF and ON.
Measures against automatic restart are handled by the upper level
FSCP.
1457
1458 Figure 46 – FS-Master power OFF  ON
1459 The FS-Device communication part is always powered by the FS-Master. Thus, if the FS-
1460 Master is switched OFF and ON, the FS-Device is just following and a regular start-up occurs.
1461 Since the FS-Master is part of an upper level FSCP system, this FSCP system is responsible
1462 to prevent from automatic restart of safety functions in this case.
1463 11.5.4.3 FS-Device with delayed SCL start

1464 Figure 47 shows the sequence chart when the SCL start within the FS-Device is delayed.

PREOPERATE (Power ON) (Delayed
SCL)
FSP_Parameter()
SDin M_SPDU(SDout, MCount=0, setSD=1, ChFAckReq=0, CRC)

1
M_SPDU(SDout, "IO-Link
MCount=0,Black Channel"
setSD=1, repeats message
ChFAckReq=0, CRC)
20 SDout
21
D_SPDU(PDin, DCount_i=7, SDset=1, DCommErr=0, DTimeout=0 ,CRC) SDout


4 24
SDout
SDin 3 23
4 24
SDout
SDin 3 23
4 24
PDout

4 24
D_SPDU(PDin, DCount_i=3, SDset=0, DCommErr=0, DTimeout=0, CRC) PDout

4 24
PDout
PDin 3 23
This example shows the case where the FS-Master waits until the
FS-Device is able to react. The FS-Master message will be repeated by
the underlying IO-Link transmission system ("Black Channel")
1465
1466 Figure 47 – FS-Device with delayed SCL start
1467 This diagram shows how an FS-Master SCL waits on the SCL of the FS-Device in case of
1468 delays. The initial SPDU of the FS-Master is repeated by the IO-Link transmission system
1469 (black channel) until the SCL of the FS-Device is ready to process in state 21.
1470 As long as the SCL of the FS-Device is not ready, the response SPDU contains all "0" and the
1471 FS-Master SCL will ignore such an SPDU. PDvalid/invalid of IO-Link is reserved for the non-
1472 safety part of the entire message.
1473 11.5.4.4 FS-Device with power OFF and ON

1474 Figure 48 shows the sequence chart when the FS-Device switches power OFF and ON again.

PREOPERATE (Power ON) (Power OFF
--> ON)
........
4 24
5 PDout
tm(MTimeout)

6
Qualifier ........ Power ON
Establish
communication
FSP_Parameter()
........
20 SDout
6 21
D_SPDU(PDin, DCount_i=7, SDset=1, DCommErr=0, DTimeout=0, CRC) SDout
ChFAckReq
6 24
SDout
SDin 8 23
ChFAckReq
6 24
SDout
SDin 8 23
ChFAckReq M_SPDU(SDout, MCount=3, setSD=1, ChFAckReq=1, CRC)
6 24
ChFAck_C=1
D_SPDU(PDin, DCount_i=4, SDset=0, DCommErr=0, DTimeout=0, CRC) SDout

4 24
D_SPDU(PDin, DCount_i=3, SDset=0, DCommErr=0, DTimeout=0, CRC) PDout
3 23 SDcycles = 0
PDin
4 24
PDout
PDin 3 23
Master SCL shall indicate "BAD" via qualifier bit for this particular
signal channel to the FSCP due to MTimeout and initiate the
acknowledgment mechanism.
1475
1476 Figure 48 – FS-Device with power OFF and ON
1477 This case assumes for example a short unplug and plug of the FS-Device causing a FAULT
1478 (MTimeout) on the FS-Master side. This FAULT causes a Qualifier bit to be set that requires
1479 via ChFAckReq (=1) an acknowledgment via ChFAck_C (=1). FS-Master and FS-Device keep
1480 SDin and SDout until this acknowledgment arrived.
1481
1482 11.5.4.6 FS-Master detects CRC signature error

1483 Figure 49 shows the sequence chart when the FS-Master detects a CRC signature error.

PREOPERATE (detects (Power ON)
CRC error)
PDin
4 24 PDout
SDin 3 23
CRC error
6 24 SDout
SDin 8 23
Qualifier ChFAckReq M_SPDU(SDout, MCount=5, setSD=1, ChFAckReq=1, CRC)
6 24 SDout

SDin 8 23
ChFAckReq
6 24 SDout

SDin 8 23
ChFAckReq
6 24 SDout
ChFAck_C=1
PDin 8 23

4 24 PDout

PDin 3 23

4 24 PDout

PDin 3 23
signal channel to the FSCP due to the discovered CRC error and
initiate the acknowledgment mechanism.
1484
1485 Figure 49 – FS-Master detects CRC signature error
1486 FS-Master received an SPDU with falsified data or falsified CRC signature which results in a
1487 "CRC error" (MCommErr). Both FS-Master and FS-Device switch to SDin and SDout
1488 respectively and the FS-Master/Gateway creates a qualifier bit and indicates a ChFAckReq
1489 signal. This signal is indicated also to the FS-Device via ChFAckReq (=1) for indication via
1490 LED (light emitting diode) to the user.
1491 FS-Master and FS-Device keep SDin and SDout until the acknowledgment ChFAck_C (=1)
1492 arrived.
1493
1494 11.5.4.7 FS-Device detects CRC signature error

1495 Figure 50 shows the sequence chart when the FS-Device detects a CRC signature error.

PREOPERATE (Power ON) (detects
CRC error)

4 24 PDout
PDin 3 23
M_SPDU(PDout, MCount=3, setSD=0, ChFAckReq=0, CRC) CRC error

4 24
SDout
SDin 3 25

6 26 SDout
SDcycles = 3
SDin 8 25
Qualifier
6 26 SDout
SDcycles = 2
SDin 8 25
ChFAckReq M_SPDU(SDout, MCount=6, setSD=1, ChFAckReq=1, CRC) SDout
6 26 SDcycles = 1
SDin 8 25
ChFAckReq
6 26 SDout
SDcycles = 0
ChFAck_C=1
SDin 8 23

4 24 PDout

PDin 3 23

4 24 PDout

PDin 3 23
signal channel to the FSCP due to a discovered CRC error and initiate
the acknowledgment mechanism.
1496
1497 Figure 50 – FS-Device detects CRC signature error
1498 FS-Device received an SPDU with falsified data or falsified CRC signature which results in a
1499 "CRC error" (DCommErr). Both FS-Master and FS-Device switch to SDin and SDout
1500 respectively caused by FS-Device Status Byte information (SDset=1 and DCommErr=1). The
1501 FS-Master/Gateway creates a qualifier bit and indicates a ChFAckReq signal. This signal is
1502 indicated also to the FS-Device via ChFAckReq (=1) for indication via LED (light emitting
1503 diode) to the user.
1504 The FS-Device runs through 3 SDcycles and afterwards FS-Master and FS-Device keep SDin
1505 and SDout until the acknowledgment ChFAck_C (=1) arrived.
1506
1507
1508
1509 11.5.5 Monitoring of safety times

1510 Figure 51 illustrates IO-Link times and safety times.
FS-Device IO-Link
FS-Master
MasterCycleTime
SCL
cycle
time Watch-
Watchdog dog
time time
SCL
cycle
time
Watch-
dog
Watchdog
time
time
1511
1512 Figure 51 – Monitoring of the SCL cycle time
1513 The base IO-Link system ("black channel") transmits SPDUs within the IO-Link
1514 MasterCycleTime (see [1], Table B.1) from the FS-Master to the FS-Device and back. The
1515 same SPDU, for example with MCount = 3, may be sent several times before the Safety
1516 Communication Layer (SCL) starts the next SCL cycle with MCount = 4. In the meantime, the
1517 FS-Master received the response SPDU from the FS-Device with DCount_i = 4.
1518 Table 30 shows timing constraints.
1519 Table 30 – Timing constraints
Item Constraints
Synchronization At each start-up and after an FS-Master timeout, the FS-Master SCL uses MCount = 0
SCL cycle time The SCL cycle time comprises the transmission time of the FS-Master SPDU, the FS-
Device processing time, the transmission time of the FS-Device response SPDU, and
the FS-Master processing time until the next FS-Master SPDU (see Figure 51)
Watchdog time The entire SCL cycle time is monitored by the watchdog timer, whose time value is
defined by the parameter FSP_Watchdog (see A.2.6).
Counter check The counter values are included in the cyclic CRC signature calculation. An incorrect
CRC signature value will already lead immediately to a safe state. The immediate
counter check in some states is used for discarding "outdated SPDUs".
Repetition Repetition in case of detected incorrect CRC signatures is not provided
PFH-Monitor The FS-Master holds the information about the reliability of both SPDU transmissions
from the FS-Device and to the FS-Device (see Table 21, bit 1). Thus, the FS-Master
monitors the average probability of a dangerous failure within a given time frame (PFH-
Monitor time). The FS-Master state machine is designed such that any corrupted
SPDU leads always to a safe state. Whenever the unlikely event of a detected
corrupted SPDU occurs during the shift of production or operation, the responsible
operator is assigned to play the role of the PFH-Monitor and can tolerate the indication
and acknowledge it. In case of frequent indications more often than once per PFH-
Monitor time, a check of the installation or the transmission quality should be
performed (see Annex H.6).
PFH-Monitor time (h) 10 FSP_ProtMode = 0x01; 16 bit CRC, see A.2.5
10 FSP_ProtMode = 0x02; 32 bit CRC, see A.2.5
1520
1521 11.5.6 Reaction in the event of a malfunction

1522 11.5.6.1 General
1523 Subclauses 11.5.6.2 to 11.5.6.10 specify possible communication errors. They are derived
1524 from clause 5.3 in IEC 61784-3, Ed.3, and refer to Table 16 in this document. Additional notes
1525 are provided to indicate the typical behavior of the IO-Link black channel.
1526 11.5.6.2 Corruption

1527 Messages may be corrupted due to errors within a communication participant, due to errors
1528 on the transmission medium, or due to message interference.
1529 NOTE 1 Bit falsifications within messages during transfer is a normal phenomenon for any standard
1530 communication system, such errors are detected at receivers with high probability by use of a hash function, in
1531 case of IO-Link a checksum (CKT or CKS), and the message is ignored (Appendix A.1, and clause 7.2.2.1 in [1] or
1532 [2]). After two retries the Master initiates a complete restart with wake-up.
1533 NOTE 2 If the recovery or repetition procedures take longer than a specified deadline, a message is classed as
1534 "Unacceptable delay" (see 11.5.6.6).
1535 Countermeasures:
1536 The CRC signature as specified in 11.4.6 detects the bit errors in messages between FS-
1537 Master and FS-Device to the extent required for SIL3 applications. The CRC signature is
1538 generated across the SPDU including the PD or SD data, and the Control&MCnt or
1539 Status&DCnt octet for cyclic communication.
1540 At start-up, the FSP parameters are sent once to the FS-Device via ISDU services. They are
1541 secured by the 16 bit FSP_ProtParCRC signature. The frequency of its occurrence is
1542 assumed to be 1/day as parameter for the calculation of the residual error rate.
1543 The CRC signature of the first SPDU sent by the SCL of the FS-Master after start-up includes
1544 the FSP_ProtParCRC signature. All following cyclic SPDUs exclude this signature.
1545 11.5.6.3 Unintended repetition

1546 Due to an error, fault or interference, messages are repeated.
1547 NOTE 1 Repetition by the sender is a normal procedure when an expected acknowledgment/response is not
1548 received from a target station, or when a receiver station detects a missing message and asks for it to be resent.
1550 The data within the black channel are transferred cyclically. Thus, an incorrect message with
1551 an SPDU that is inserted once will immediately be overwritten by a correct message. The
1552 thereby possible delay of a demand can be one DTime/MTime.
1553 11.5.6.4 Incorrect sequence

1554 Due to an error, fault or interference, the predefined sequence (for example natural numbers,
1555 time references) associated with messages from a particular source is incorrect.
1556 NOTE 1 In IO-Link only one sequence is active from one source, the message handler.
1558 The receiver will detect any incorrect sequence due to the stringently sequential expectation
1559 of the MCount and DCount values.
1560 11.5.6.5 Loss

1561 Due to an error, fault or interference, a message or acknowledgment is not received.
1563 Lost information will be detected by stringently changing and examining the MCount/DCount
1564 and/or MTime/DTime within the safety communication layer of the respective receiver.
1565 11.5.6.6 Unacceptable delay

1566 Messages may be delayed beyond their permitted arrival time window, for example due to bit
1567 falsifications in the transmission medium, congested transmission lines, interference, or due
1568 to communication participants sending messages in such a manner that services are delayed
1569 or denied (for example FIFOs in switches, bridges, routers).
1570 NOTE 1 IO-Link provides a point-to-point communication interface with defined message sequences and thus the
1571 probability for congestion and storage of messages is very low.
1573 A consecutive counter in each message (MCount/DCount) together with a watchdog timer
1574 (MTime/DTime) will detect unacceptable delays.
1575 11.5.6.7 Insertion

1576 Due to a fault or interference, a message is received that relates to an unexpected or
1577 unknown source entity.
1578 NOTE 1 These messages are additional to the expected message stream, and because they do not have
1579 expected sources, they cannot be classified as Correct, Unintended repetition, or Incorrect sequence.
1580 NOTE 2 IO-Link provides a point-to-point communication interface (Port) and thus the probability for insertion of
1581 messages is very low.
1584 of the MCount and DCount values.
1585 11.5.6.8 Masquerade

1586 Due to a fault or interference, a message is inserted that relates to an apparently valid source
1587 entity, so a misdirected non-safety related message may be received by a safety related
1588 participant, which then treats it as safety related correct message.
1589 NOTE 1 Communication systems used for safety-related applications can use additional checks to detect
1590 Masquerade, such as authorised source identities and pass-phrases or cryptography.
1595 of the MCount and DCount values. After changes of wiring, the FS-Devices can detect
1596 misconnections through the FSP_Authenticity1/2 and FSP_Port parameters (see A.2.1 and
1597 A.2.2) at start-up.
1598 11.5.6.9 Addressing

1599 Due to a fault or interference, a safety related message is delivered to the incorrect safety
1600 related participant, which then treats reception as correct. This includes the so-called
1601 loopback error case, where the sender receives back its own sent message.
1602 NOTE 1 The probability of not detecting a misdirected non-safety related message is lower than the probability of
1603 not detecting a misdirected safety related message since the SPDU structures are similar due to the shared
1604 protocol procedures.
1609 of the MCount and DCount values. After changes of wiring, the FS-Devices can detect
1610 misconnections through the FSP_Authenticity1/2 and FSP_Port parameters (see A.2.1 and
1611 A.2.2) at start-up.
1612 11.5.6.10 Loop-back

1613 A special addressing error is the so-called loopback error case, where the sender receives
1614 back its own sent message.
1616 IO-Link Safety provides for inverted values for MCount and DCount from the FS-Device.
1617 11.5.7 Start-up (communication)

1618 An FS-Device starts always after an FS-Master since the FS-Master shall be the only one to
1619 power-up at least the communication part of the FS-Device. Both devices usually require time
1620 for safety self-tests that may exceed the standard timings defined in [1].
1621 Due to the initial behavior of an FS-Device as an OSSDe, the start-up is coordinated and
1622 specified in 5.7, 7.2, and 7.3.
1623 The start-up of the underlying IO-Link communication system is specified in [1] and Figure 55.
1624 Any deviating FSP authenticity or protocol parameter CRC signature shall lead to a safe state
1625 of the particular FS-Master port.
1626 11.6 SCL management

1627 11.6.1 Parameter overview (FSP and FST)
1628 Annex A specifies a number of functional safety related parameters for communication
1629 protocol services (FSP) as well as for the handling and integrity purposes of FS-Device
1630 technology parameters (FST).
1631 The parameters are subdivided into 4 groups:
1632 • Authenticity
1633 • Safety communication
1634 • FS-I/O structure description
1635 • Auxiliary parameters
1636 The authenticity parameters combine the safety connection ID ("A-Code") of the FS-Master
1637 (assigned by the upper level FSCP system) with the port number of the connected FS-Device.
1638 Due to the point-to-point nature of the FS-Device communication with its Master, a one-time
1639 check at start-up is sufficient to ensure authenticity (see 11.7.5).
1640 The Safety Communication Layers (SCL) require parameters for protocol versions, protocol
1641 modes such as CRC-16 or CRC-32, watchdog for timeliness, CRC signature to secure
1642 technology parameters, and a CRC signature to secure the safety communication parameters.
1643 The next group contains a description of the FS I/O data structure, the FS-Device wants to
1644 exchange with the FSCP-Host. This description facilitates the mapping to the description
1645 which some FSCP systems require for set-up. During the mapping process the FS-Master tool
1646 appends the qualifier bits, which are necessary for port-selective passivation.
1647 Auxiliary parameters are specified for several purposes. For example, to secure the functional
1648 safety parameter description within the IODD, to support the automatic calculation of the
1649 minimum watchdog time, to protect parameters from unauthorized access via a password, and
1650 to enable invocation of an associated IOPD tool.
1651 Figure 52 shows an overview of the components and the activities around parameterization.
1652 An FS-Master as a gateway comes with a parameter description file for the FSCP system.
1653 With the help of an engineering tool and these parameters, the FS-Master receives during
1654 commissioning for example its FSCP connection ID ("A-Code" for authenticity) and its FSCP
1655 watchdog time ("T-Code" for timeliness). Thus, the FSCP communication cycles are
1656 independent from the IO-Link safety communication cycles between FS-Master and FS-
1657 Device.
FSCP: FS-Master
Engineering
description file
tool
TCI, FDT, FDI, Proprietary, etc.

FSCP-Host
FS-Master Tool
invocation
FSCP
FS-Master
tool
Proprietary
FS-Master
IO-Link communi-
cation (OD)
Protocol Technology
parameter parameter
FS-
Device IODD IOPD
"Dedicated
Tool"
1658
1659 Figure 52 – Parameter types and assignments
1660 An FS-Master with its IO-Link side can be configured and parameterized with the help of its
1661 FS-Master tool. The IODD of an FS-Device contains besides the non-safety parameters also
1662 the safety section with the parameters in Annex A. The parameters can be set-up off-line or
1663 online the same way as with a non-safety system. The FSCP authenticity parameter can be
1664 copied from the engineering tool display to the IO-Link system FS-Master tool display (see
1665 A.2.1).
1666 It is possible to describe a small set of technology parameters (FST) in a non-safety manner,
1667 thus allowing the usage of the IO-Link standard data storage mechanism as described in 9.4.
1668 However, a separate dedicated IOPD tool, developed according IEC 61508-3 shall be used to
1669 calculate a CRC signature across the instance of the FST parameters. This CRC signature
1670 shall be entered into the corresponding FSP parameter (see A.2.7).
1671 The IOPD tool uses a new standardized IOPD communication interface and the same path to
1672 the FS-Device as the FS-Master tool itself.
1673 11.6.2 Parameterization approaches

1674 11.6.2.1 FS-Master-centric
1675 The configuration and parameterization of a stand-alone IO-Link safety system corresponds
1676 mainly to the approach described in 11.6.1. The authenticity uses a default value in this case
1677 (see A.2.1).
1678 Figure 52 shows a loosely coupled system, where the parameterization is performed within
1679 the IO-Link safety part. Within the FSCP system, predefined FS I/O data structures are
1680 available and can be selected during commissioning.
1681 11.6.2.2 FSCP-Host-centric

1682 Some automation application areas prefer an FSCP-Host-centric approach. In this case, all
1683 parameters are expected to be stored within the FSCP-Host and downloaded at start-up into
1684 the FS-Master (FSCP-subsystem) and further down into the FS-Device.
Engineering FSCP: FS-Master

tool description file

FSCP-Host
FS-Master Tool Composer

invocation
FSCP tool
FS-Master
tool
FS-Master
IO-Link communi-
cation (OD)
Protocol Technology
parameter parameter
FS-
Device IODD IOPD
"Dedicated
Tool"
1685
1686 Figure 53 – FSCP-Host-centric system
1687 Due to the fieldbus-independent design of IO-Link and IO-Link safety, all parameters are
1688 mapped into the fieldbus device description file (for example EDS, GSD, etc.) with the help of
1689 a Composer tool. It is one of the objectives of IO-Link safety to optimize the design of safety
1690 parameters such that an efficient mapping is possible.
1691 11.7 Integrity measures

1692 11.7.1 IODD integrity
1693 The parameters specified in Annex A are coded in an IODD file using XML. In order to protect
1694 the safety parameter description within this file, a CRC signature ("FS_IODD_CRC") shall be
1695 calculated across its safety-related parts (see Annex D and Annex E.3). Usually, the IODD file
1696 travels many ways and the CRC signature helps detecting potentially scrambled bits.
1697 11.7.2 Tool integrity

1698 When opening the IODD, the FS-Master tool (interpreter of the IODD file) shall calculate the
1699 CRC signature across the safety-related parts and compare the result with the parameter
1700 "FSP_ParamDescCRC".
1701 During the data manipulations within the FS-Master tool as well as within Device Tools/IOPDs
1702 ("Dedicated Tools") such as display, intended modification, storage/retrieval, and
1703 down/upload, parameter values could become incorrect. It is the responsibility of the designer
1704 to develop the tools fulfilling the requirements of IEC 61508-3 or ISO 13849-1 for software
1705 tools classified as T3.
1706 In case of an FSCP-Host-centric system, these requirements apply for the Composer and the
1707 Engineering tool.
1708 11.7.3 Transmission integrity

1709 Since communication between the FS-Master tool and the FS-Device is proprietary, it is the
1710 responsibility of the FS-Master tool to ensure transmission integrity and authenticity, for
1711 example through CRC signatures and/or read back (see Table 16 and D.3.1).
1712 11.7.4 Verification and validation

1713 It is the responsibility of the FS-Device designer to specify the necessary verification and
1714 validation steps (for example tests; see H.6) within the user/safety manual and/or within the
1715 "dedicated tool" (IOPD).
1716 11.7.5 Authenticity

1717 In either the FS-Master-centric or in the FSCP-Host-centric approach a record of parameter
1718 data is stored in the FS-Master per port/FS-Device as shown in Figure 54.
FSP parameter record

FS-Device specific header
FSP parameter 0 UIntegerT (32)

1 FSP_Authenticity1
2
(FSCP dependent)
4 UIntegerT (32)
5
FSP_Authenticity2
(extension)
6 (FSCP dependent)
7
8 FSP_Port UIntegerT (8)

CRC signature to 9 UIntegerT (16)
FSP_AuthentCRC
be transfered at
protocol start 10
11 FSP_ProtVersion UIntegerT (8)

12 FSP_ProtMode UIntegerT (8)
13 FSP_WatchdogTime UIntegerT (16)
14
15 FSP_IO_StructCRC UIntegerT (16)

16
17 FSP_TechParCRC
UIntegerT (32)
18
19
20
CRC signature to
21 FSP_ProtParCRC
be transfered at
22 UIntegerT (16)
protocol start
End of FSP parameter record
1719
1720 Figure 54 – Structure of the protocol parameter (FSP) record
1721 The authenticity parameters are secured by FSP_AuthentCRC for transmission from FS-
1722 Master Tool to FS-Master and further to the FS-Device. The procedure of the FSCP
1723 authenticity acquisition from the FSCP gateway and subsequent handling of the FSP authen-
1724 ticity record is described in 10.2.3.3.
1725 11.7.6 Storage integrity

1726 Both parameter records (authenticity and protocol) of Figure 54 are stored in both FS-Master
1727 and FS-Device and may fail over time (see also Table A.1).
1728 At each start-up, the FS-Master transfers both parameter records to the FS-Device during
1729 PREOPERATE as shown in Figure 55 and described in 10.2.3.1.
1730 The FS-Device will detect a potential mismatch between the downloaded authenticity
1731 parameter set and the already stored values in the FS-Device, for example if FS-Devices are
1732 misconnected to a different port or even to a different FS-Master. The FS-Device stores
1733 authenticity parameters only during commissioning, i.e. when the FSP_TechParCRC signa-
1734 ture value is "0". When the FSP_TechParCRC signature value is ≠ "0", The FS-Device will
1735 only compare the stored authenticity values with the newly transferred values.
1736 The protocol parameters are propagated to the safety communication layer at each start-up.
1737 The protocol engine detects any mismatch between the locally stored parameters (for
1738 example due to falsified bits) and the newly transferred record during initialization and blocks
1739 safety communication.
Communication,
STARTUP
Identification
Standard
START Input/Output
(SIO/OSSD)
Cyclic Configure,
OPERATE Process Data PREOPERATE
Parameterize
exchange
Authent + Protocol
3. Block Authent if
2. Transfer of FSP
1. "Restore" if FS-
TechParCRC <>0
Device replaced
communication
IO-Link Safety
Two cases:
1. Replacement
2. Misconnection
1740
1741 Figure 55 – Start-up of IO-Link safety
1742 In case the FS-Device has been replaced due to a failure, the technology specific parameters
1743 (FST) and the FSP parameters are "restored" from Data Storage if the FS-Device caries all
1744 Authenticity parameters = "0". If Authenticity is not "0", the FS-Device shall ignore them and
1745 keep the existing (see 9.4, E.5.7, and step 1. in Figure 55). In this case a misconnection can
1746 be assumed or the FS-Device has already been in use and requires testing and a reset of the
1747 Authenticity parameters (see Annex G).
1748 11.7.7 FS I/O data structure integrity

1749 All I/O data of the connected FS-Devices should be mapped in an efficient manner into the
1750 FSCP I/O data as shown in 12.1.
1751 Due to the additional qualifier bits required for port-selective passivation, the original FS-
1752 Device specific data structure is not directly visible within the FSCP I/O data structure
1753 exchanged with the FSCP-Host.
1754 The safety-related interpreter of the FS-Master Tool transfers the entire instance data
1755 together with the CRC signature to the FS I/O data mapper as shown in 10.2.3.1 (see also
1756 A.2.9).
1757 11.7.8 Technology parameter (FST) based on IODD

1758 One of the objectives of IO-Link safety is FS-Device exchange without tools by using the
1759 original data storage mechanism of IO-Link. As a precondition, the FST-parameter description
1760 is required within the IODD (see E.5.7).
1761 The FST parameters are displayed in this case within the FS-Master tool (see Figure 56, FST-
1762 Parameters section). Values can be assigned as with non-safety parameters.
Topology Identification Parameter Monitoring Diagnosis Device Library

Toplevel Vendor 1
… IO-Link Safety FSP - Device a V1.03
- Master FSP_Watchdog - Device b V1.23
- Port 1: Device aa - Device c V2.00
- Port 2: Device b FSP_Protocol - …
-…  Device Tool menu (PID) Vendor 2
- Port n: Device xxx FSP_Portmode - Device aa V0.99
- Device bb V1.1.2
FSP_Safety-Level -…
FSP_TechParCRC 0x3AF2 …
Vendor n
Device Tool THC26 Transfer CRC
- Device xxx signature
V2.3.04
value-- Device
via clipboard
yyy V1.3
Device zzz V123
Technology parameters (FST)
Filter 26
Discrepancy 5
Redundancy yes
Two hand control THC26
Test cycle 3
Filter 26
Discrepancy 5
Redundancy yes
 Confirm values
Transfer instance Test cycle 3
values via TPF CRC signature 0x3AF2 Confirm

1763
1764 Figure 56 – Securing of FST parameters via dedicated tool
1765 After test and validation, the Device Tool is invoked via menu (step). Instance values are
1766 transferred via TPF (step) and displayed again. The user compares the instance values and
1767 confirms the correctness via the "Confirm" button (step). The Device Tool then calculates
1768 the CRC signature across the instance data of the FST parameters (see "CRC signature" in
1769 Figure 56), which can be copied and pasted into the "FSP_TechParCRC" field of the FSP
1770 parameters (step ).
1771 Since this parameter is part of the FSP parameter block, the FS-Device can check the
1772 integrity of these FST parameters together with the protocol parameters.
1773 11.7.9 Technology parameter (FST) based on existing dedicated tool (IOPD)
1774 In cases, where existing safety devices already have their PC program with password
1775 protection, wizards, teach-in functions, verification instructions, online monitoring, diagnosis,
1776 special access to device history for the manufacturer, etc., an FST parameter description may
1777 not be available. Figure 57 shows an example.

Toplevel Vendor 1
-… Vendor 2
Transfer CRC- Device
signature
bb V1.1.2
FSP_Safety-Level
value via clipboard
-…
FSP_TechParCRC 0x34FA2C43 …
Vendor n
Device Tool Configure field - Device xxx V2.3.04
- Device yyy V1.3
- Device zzz V123
Status/diagnosis
 Device Tool menu (PID)
CRC signature: 0x34FA2C43
Transfer network
information via TPF
1778
1779 Figure 57 – Modification of FST parameters via Device Tool

1780 Such a Device Tool requires communication with its particular FS-Device and therefore
1781 access to a Communication Server (see Annex F.5). It can be invoked via menu entries
1782 (step) and thus jump directly into for example configuration or status/diagnosis functions.
1783 Network information is transferred via TPF (step). After test and validation, it shall provide a
1784 display of the calculated CRC signature across the instance data, which can be copied and
1785 pasted into the "FSP_TechParCRC" field of the FSP parameters (step).
1786 These FS-Devices shall be supported by the data storage mechanism of IO-Link and an FS-
1787 Device replacement without tools is possible.
1788 The Data Storage limit per FS-Device is 2048 octets according to [1].
1789 11.8 Creation of FSP and FST parameters

1790 Standards for "Safety-for-Machinery" such as ISO 13849-1 and IEC 62061 require "dedicated
1791 tools" for the parameterization of safety devices. For the ease of development and logistics of
1792 software tools it is recommended to use the process described in Figure 58.
1793 For FS-Devices with only a few FST parameters, no business logic, and no wizard and help
1794 systems, one particular "Interpreter Framework" should be developed in a safe manner
1795 according to IEC 61508 and equipped with the necessary communication interfaces. The
1796 result will be made available for the whole IO-Link Safety community as a development kit at
1797 a certain fee. The FS-Device developer can create an individual "Internal IODD" for the FST
1798 parameters of a particular FS-Device (Option 1 in Figure 58). The "Interpreter Framework"
1799 together with the individual "Internal IODD" will then be compiled using the brand name,
1800 company and FS-Device identifiers to one dedicated tool (IOPD). This executable software
1801 can be certified by assessment bodies.
1802 For FS-Devices with more complex FST parameters, the IOPD can be developed individually
1803 or existing tools can be used. In both cases the tools can be equipped with the necessary
1804 communication interfaces (Option 2 in Figure 58).
Dedicated tool (IOPD), FS-Master Dedicated tool (IOPD),

Type "C2" (certified) tool PCDT Type "C3" (certified)
InterpreterSW
Classified
as T3
Development
Compile synergy!? Compile
(Development Interpreter framework FS protocol

kit by with store, print, comm parameter (FSP)
technology (precertified)
provider) Add IO-Link
Classified IODD "comm driver"
as T3
1. IODD Checker Mandatory

2. CRC calculations
"Internal IODD" for FS

Option 1 Option 2
technology parameters
Non-complex FS-Devices 1. Existing parameterization

FS-Device and diagnostic tool, or
with few FST parameters
2. Complex FS-Devices
Key IOPD = IO-Link Parameterization & Diagnostic T3 = software tools are classified T3 according ISO 13849 and IEC 61508-3
1805
1806 Figure 58 – Creation of FSP and FST parameters
1807 In any case, the dedicated tool (IOPD) shall calculate and display the CRC signature across
1808 all FST parameters. This signature can be copied into the entry field of the FSP parameter
1809 "FSP_TechParCRC", such that an FS-Device can verify the correctness of locally stored FST
1810 parameters after start-up and download of the FSP parameter set to the FS-Device.
1811 For each and every FS-Device the same set of FSP (protocol) parameters shall be created in
1812 an extended IODD. This IODD is mandatory and contains the usual conventional parameters
1813 and additionally the FSP parameters.
1814 11.9 Integration of dedicated tools (IOPD)

1815 11.9.1 IOPD interface
1816 Usually, a so-called Master-Tool (PCDT) provides engineering support for a Master and its
1817 Devices via Device descriptions in form of XML files (IODD). In principle, this is the same for
1818 FS-Master and FS-Device. For functional safety besides an extended IODD it is necessary for
1819 an FS-Device vendor to provide an additional Dedicated Tool (IOPD) as shown in Figure 58.
1820 In order for the IOPD to communicate with its FS-Device a new standardized communication
1821 interface is required.
1822 11.9.2 Standard interfaces

1823 Usually, Master Tools are integrated using existing standards such as FDT, the upcoming
1824 FDI, or proprietary solutions. Such a variety is not acceptable for FS-Devices and therefore,
1825 easy and proven-in-use technology has been selected and adopted for IO-Link. It is called
1826 "Device Tool Interface" (DTI).
1827 Annex F provides the specification for this interface.
1828 Figure 59 illustrates the communication hierarchy of FDT and others for the fieldbus as well
1829 as the connection via the "Device Tool Interface" and the underlying IO-Link communication.
1830 The FS-Device Tool (IOPD) does not have to know about the fieldbus environment it is
1831 connected to. The example in Figure 59 illustrates how it sends a "Read Index 0x4231"
1832 service and how the FS-Master Tool packs this service into a fieldbus container and passes it
1833 to the fieldbus communication server.
1834 The addressed FS-Master is connected to the fieldbus and receives this container. It unpacks
1835 the IO-Link Read service and performs it with the addressed FS-Device connected to a port.
FS-Master Tool IODD

Engineering
System (FS-PCDT)
Dedicated Tool
Port Inter- Device Tool software (safety)
FDT, Configur- preter Interface (DTI)
TCI, or ation
others FS-Device
Tool
Backward
channel for
read/write Example:
parameters
"Read Index 0x4231"
Access to Tunneling
IO-Link to IO-Link
Master Device
CommServer
IO-Link
Example:
Fieldbus container "Read Index 0x4231"
Communication
driver CommServer
Fieldbus
1836
1837 Figure 59 – Example of a communication hierarchy

1838 11.9.3 Backward channel

1839 An FS-Master vendor does not know in advance which FS-Devices a customer wants to
1840 connect to the FS-Master ports. As a consequence, the fieldbus device description of such an
1841 FS-Master can only provide predefined "containers" for the resulting I/O data structure of the
1842 FS-Device ensembles connected to the ports. In functional safety this is even more
1843 complicated since the description of the data structures shall be coded and secured.
1844 As a consequence of the variety of different configurations and parameterizations of a

1845 particular FS-Device, it usually for example
1846 • requires different I/O data structures to exchange with PLCs or hosts;
1847 • has different reaction times due to configured high or low resolutions;
1848 • can have different SIL, PL, category, or PFH values impacting the overall safety level of a
1849 safety function.
1850 The classic "fieldbus device description" to inform an engineering system is not flexible in this
1851 respect. Its advantage is the testability and certification for its interoperability with engineering
1852 tools.
1853 Nevertheless, a "backward channel" within the tool interfaces allows for nowadays flexible
1854 manufacturing and ease of engineering and commissioning. An example is specified in [15]
1855 clause 4.15.5.
1856 Annexes F.3.5 and F.9.4 specify an extension for this "backward channel".
1857 11.10 Passivation

1858 11.10.1 Motivation and means
1859 Figure 60 illustrates the motivation for Port selective passivation. Usually for efficiency
1860 reasons, the signals 0 to 7 of FS-Devices connected to Ports are not mapped individually to
1861 an FSCP-PDU, but rather packed into one FSCP-PDU. Each of these signals can be assigned
1862 to a separate safety function n to n+7. If a fault occurs in one of the signal channels, a
1863 collective passivation for the entire FSCP-PDU would be necessary causing all safety
1864 functions to trip.
FSCP-PDU Qualifier Signals

Trailer Fieldbus with FSCP
FS-Master
0 Signal channel 0; safety function n
Signal channel 6; safety function n+6

7 Signal channel 7; safety function n+7
1865
1866 Figure 60 – Motivation for Port selective passivation
1867 FSCPs usually provide so-called qualifier bits associated to the signal process data, which
1868 enable selectively passivating that particular signal channel and the associated safety
1869 function.
1870 Safety of machinery usually requires an operator acknowledgment after repair of a defect
1871 signal channel to prevent from automatic restart of a machine. It is not necessary to provide
1872 the acknowledgment for each signal channel and it can be one for all the channels.
1873 11.10.2 Port selective (FS-Master)

1874 In 11.10.1 a use case is described where the signal channel corresponds directly with a
1875 particular FS-Device. The qualifier and acknowledgement mechanism shall be implemented
1876 within the FS-Master in accordance with the specifications of the particular FSCP.
1877 It can be helpful for the user to provide an indication in each FS-Device that an operator
1878 acknowledgment is required prior to a restart of a safety function. CB0 (ChFAckReq) within
1879 the Control&MCnt octet (see Table 20) shall be used for that purpose. It is not safety-related.
1880 Optionally, in case of FS_PortMode "OSSDe" (see 10.2.2), the signal ChFAckReq can be
1881 connected separately to the corresponding FS-Device indication (see H.1).
1882 11.10.3 Signal selective (FS-Terminal)

1883 Figure 13 shows the use case of an FS-Terminal where an FS-Device provides several signal
1884 channels to switching devices such as E-Stop buttons.
1885 For those FS-Devices the design rules in 11.4.7.3 apply. The acknowledgment mechanisms
1886 shall be implemented within the safety Process Data.
1887 11.10.4 Qualifier settings in case of communication

1888 Figure 61 illustrates the embedding of the qualifier handler in case of FS_PortModes
1889 "SafetyCom" and "MixedSafetyCom" (see 10.2.2). The services/signals "FAULT_S",
1890 "SDset_S", "ChFAckReq_S", and "ChFAck_C" are specified in 11.3.2 and 11.5.2.
IO-Link Safety FSCP

(FS-Master) (FS-Gateway)
FAULTS_S Faults
≥1 "GOOD/BAD" qualifier
SDset_S
Qualifier
handler
FSCP Operator request
ChFAckReq_S
and acknowledgment (AckQ)
ChFAck_C
1891
1892 Figure 61 – Qualifier handler (communication)
1893 The qualifier bits "GOOD/BAD" shall be set according to the definitions in Table 31 during the
1894 FSCP mapping procedure.
1895 Table 31 – Qualifier bits "GOOD/BAD"
Faults Qualifier Signal state
0 GOOD 1
1 BAD 0
1896
1897 11.10.5 Qualifier handling in case of OSSDe

1898 Figure 62 illustrates the embedding of the qualifier handler in case of FS_PortModes
1899 "OSSDe" (see 10.2.2). Definitions of Table 31 apply.
OSSDe FSCP
(FS-Master) (FS-Gateway)
Faults
OSSDe test "GOOD/BAD" qualifier
Qualifier
handler
FSCP Operator request
ChFAckReq and acknowledgment (AckQ)
1900
1901 Figure 62 – Qualifier handler (OSSDe)
1902 Figure 63 shows the state machine for the behavior of the qualifier handler (OSSDe).
/Initialization
Port_OSSDe_Check_1
[No Faults]/ [Faults]/

T1 T2
[Faults appeared]/
OSSDe_OK_GOOD_2 T3 OSSDe_Fault_BAD_3
[Faults gone]/
T4
[RisingEdge_of_AckQ]/ [Faults appeared]/

T5 T6
NoFault_AwaitAckQ_4
1903
1904 Figure 63 – Qualifier behavior per FS-Master port
1905 Table 32 shows the state and transition table for the qualifier behavior.
1906 Table 32 – State transition table for the qualifier behavior
Initialization Use SD, Qualifier = BAD, ChFAckReq =0

1 Port_OSSDe_Check Perform Port diagnosis to detect Faults
2 OSSDe_OK_GOOD Perform Port diagnosis cyclically to detect Faults
3 OSSDe_Fault_BAD Perform Port diagnosis cyclically to detect Faults
4 NoFault_AwaitAckQ Wait on rising edge of AckQ
1907
SITION STATE STATE
T1 1 2 Use PD, Qualifier = GOOD, AckQ = 0, ChFAckReq =0

T2 1 3 Use SD, Qualifier = BAD, AckQ = 0, ChFAckReq =0
T5 4 2 Use PD, Qualifier = GOOD, AckQ = 1, ChFAckReq =0
1908
RisingEdge_of_AckQ Flag Means to prevent from permanently actuating the AckQ signal.
AckQ Flag Flag depending on the individual upper level FSCP system and its mapping.
Faults Flag Any detected fault such as a wire break, short circuit.
ChFAckReq Flag Signal set by qualifier handler (see 11.10.2 and H.1)
1909
1910 11.11 SCL diagnosis

1911 The Safety Communication Layer can create its own EventCodes such as CRC error, counter
1912 error, or timeout as listed in Annex B.1.
1913 12 Functional safe processing (FS-P)

1914 12.1 Recommendations for efficient I/O mappings
1915 Figure 64 shows how efficiency can be increased when packing I/O data from the connected
1916 safety devices into one FSCP SPDU instead of several individual FSCP SPDUs. On the left,
1917 the bits of safety devices (OSSD) are packed into one FSCP SPDU by the FS-DI module. On
1918 the right, the FS-Devices use each an FSCP SPDU to transmit a bit. In the middle an IO-Link
1919 Safety FS-Master/Gateway packs bits into one FSCP SPDU similar to an FS-DI.
Host: Safety-PLC
FSCP
Length: 4 x (x+1) octets
Message length: x + 1 octets Message length: x + 1 octets (Each bit has its own safety code)
(Bits packed within one message) (Bits packed within one message)
Safety Code x Safety Code x 1 SC x 2 SC x 3 SC x 4 SC x
RIO FS-DI IOL-M IOL-M
Safety
Switches, FS-Devices 1 2 3 4
1 2 3 4
OSSDs
Usually 1 data bit per safety device Usually 1 data bit per FS-Device Usually 1 data bit per FS-Device
1920
1921 Figure 64 – Mapping efficiency issues
1922 The FS I/O data structure shall be created as a multiple of 16 bits.
1923 12.2 FS logic control

1924 Specification and implementation of an FS logic control to provide local safety functions are
1925 manufacturer's responsibility and not standardized (see  in clause 1 and Figure 2).
1926 Annex A
1927 (normative, safety-related)
1928
1929 Extensions to parameters
1930
1931 A.1 Indices and parameters for IO-Link Safety

1932 The Index range reserved for IO-Link Safety includes 255 Indices from 0x4200 to 0x42FF.
1933 Table A.1 shows the specified Indices for IO-Link profiles, the protocol parameters (FSP) of
1934 IO-Link Safety, comprising authenticity, protocol, I/O data structures, and auxiliary blocks as
1935 well as the total reserved range for IO-Link Safety, and the second range of Indices for IO-
1936 Link profiles.
1937 Table A.1 – Indices for IO-Link Safety
Index Sub Object name Access Length Data type M/O/ Purpose/reference
(dec) index C
…
0x4000 Profile specific For example: Smart sensors
to Indices
0x41FF
Authenticity (11 octets)
0x4200 1 FSCP_Authen- R/W 4 octets UIntegerT M "A-Code" from the upper level
(16896) ticity_1 FSCP system; see A.2.1
2 FSCP_Authen- R/W 4 octets UIntegerT M Extended "A-Code" from the
ticity_2 upper level FSCP system
3 FSP_Port R/W 1 octet UIntegerT M PortNumber identifying the
particular FS-Device; see A.2.2
4 FSP_Authent R/W 2 octets UIntegerT M CRC-16 across authenticity
CRC parameters; see A.2.3
Protocol (12 octets)
0x4201 1 FSP_ R/W 1 octet UIntegerT M Protocol version: 0x01; see
(16897) ProtVersion A.2.4
2 FSP_ R/W 1 octet UIntegerT M Protocol modes, e.g. 16/32 bit
ProtMode CRC; see A.2.5
3 FSP_ R/W 2 octets UIntegerT M Monitoring of I/O update;
Watchdog 1 to 65 535 ms; see A.2.6
4 FSP_IO_ R/W 2 octets UIntegerT M CRC-16 signature across I/O
StructCRC structure description block; see
A.2.9
5 FSP_TechParCRC R/W 4 octets UIntegerT M Securing code across FST
(technology specific parameter);
see A.2.7
6 FSP_Prot R/W 2 octets UIntegerT M CRC-16 across protocol
ParCRC parameters; see A.2.8
Auxiliary parameters
0x4210 FS_ W 32 StringT M Password for access protection
(16912) Password octets of FSP parameters and
Dedicated Tools; see A.2.10
0x4211 Reset_FS_ W 32 StringT M Password to reset the FST
(16913) Password octets Parameters to factory settings
and to reset implicitly the FS-
Password; see A.2.11
Index Sub Object name Access Length Data type M/O/ Purpose/reference
(dec) index C
0x4212 FSP_ R 2 octets UIntegerT M CRC-16 signature securing

(16914) ParamDescCRC authenticity, protocol, and FS
I/O structure description within
IODD; see A.2.12
…
0x4213 Reserved for IO-
(16915) Link Safety
to
0x42FF
(17151)
0x4300 Profile specific For example: Firmware update
to Indices and BLOB
0x4FFF
…
Key M = mandatory; O = optional; C = conditional
1938
1939 A.2 Parameters in detail

1940 A.2.1 FSCP_Authenticity
1941 During off-line commissioning of an IO-Link Safety project, the default value of this parameter
1942 is "0". During on-line commissioning, the FS-Master acquires the FSCP authenticity ("A-
1943 Code") from the FSCP gateway as described in 10.2.3.1. The FS-Device receives this
1944 parameter at each start-up. In case of FSP_TechParCRC = "0", it either stores the
1945 authenticity parameter or rejects it with an error message if the value is "0" (see Table B.1). In
1946 case the system is armed (FSP_TechParCRC ≠ "0") the FS-Device only compares its locally
1947 stored value with the transferred value to detect any misconnection (incorrect port or FS-
1948 Master), see Annex G.
1949 Some FSCPs provide extended authenticity. In those cases, the extended code shall be
1950 included in this parameter.
1951 Padding bits and octets shall be filled with "0".
1952 A.2.2 FSP_Port

1953 The FS-Master Tool identifies the FS-Master PortNumber of the attached FS-Device and
1954 stores it in this parameter. Storage and checking of the parameter by the FS-Device
1955 corresponds to A.2.1. Numbering starts at "1". Default PortNumber in IODD is "0" and means
1956 PortNumber of a particular Device has not been assigned yet.
1957 A.2.3 FSP_AuthentCRC

1958 For the CRC signature calculation of the entire authenticity block, the CRC-16 in Table D.1
1959 shall be used. This CRC polynomial has a Hamming distance of ≥ 6 for lengths ≤ 16 octets. A
1960 seed value "0" shall be used (see D.3.6).
1961 A.2.4 FSP_ProtVersion

1962 Table A.2 shows the coding of FSP_ProtVersion.
1963 Table A.2 – Coding of protocol version
Value Definition
0x00 Reserved
0x01 This protocol version
0x02 to 0xFF Reserved
1964
1965 A.2.5 FSP_ProtMode

1966 Table A.3 shows the coding of FSP_ProtMode.
1967 Table A.3 – Coding of protocol mode
Value Definition
0x00 Reserved
0x01 0 to 4 octets of FS I/O Process Data; 16 bit CRC
0x02 0 to 26 octets of FS I/O Process Data; 32 bit CRC
0x03 to 0xFF Reserved
1968
1969 A.2.6 FSP_Watchdog

1970 The FS-Device designer determines the I/O update time and uses it as default value of this
1971 parameter within the IODD. The I/O update time is the time period between two safety PDUs
1972 with subsequent counter values (I/O samples) including possible repetitions within the IO-Link
1973 communication layer (black channel; see 11.5.5).
1974 With the help of the parameter default value (I/O update time), the transmission times of the
1975 safety PDUs, and FS-Master processing times, the FS-Master Tool can estimate the total time
1976 and suggest the value of the "FSP_Watchdog" parameter.
1977 The value range is 1 to 65 535 (measured in ms). A value of "0" is not permitted. The SCL of
1978 the FS-Device is responsible to check the validity at start-up and to create an error in case
1979 (see Table B.1).
1980 A.2.7 FSP_TechParCRC

1981 This document specifies two basic methods for the assignment of technology specific
1982 parameters (FST). The FS-Device designer is responsible for the selection of the securing
1983 method.
1984 The method in 11.7.8 is based on IODD and suggests using one of the CRC generator
1985 polynomials in Table D.1. If calculation of the CRC signature value results in "0", a "1" shall
1986 be used.
1987 The method in 11.7.9 depends on the method used within an existing FS-Device Tool
1988 (Dedicated Tool). Whatever method is used, the tool shall display a securing code after
1989 verification and validation that can be copied and pasted into the FSP_TechParCRC
1990 parameter entry field.
1991 During commissioning a value of "0" can be entered to allow for certain behavior of the IO-
1992 Link Safety system (see 10.2.3.1). During production, this value shall be ≠ "0".
1993 For technology specific parameter block transfers > 232 octets, the BLOB mechanism (Binary
1994 Large Objects) specified in [13] can be used.
1995 A.2.8 FSP_ProtParCRC

1996 For the CRC signature calculation of the entire protocol block, the CRC-16 in Table D.1 shall
1997 be used. This CRC polynomial has a Hamming distance of ≥ 6 for lengths ≤ 16 octets. A seed
1998 value "0" shall be used (see D.3.6).
1999 A.2.9 FSP_IO_StructCRC

2000 An IODD-based non-safety viewer can be used to calculate this 16 bit CRC signature across
2001 the FS I/O structure description within the IODD during the development phase. The algorithm
2002 for the calculation is shown in Annex D. A seed value "0" shall be used (see D.3.6).
2003 The safety-related interpreter of the FS-Master Tool transfers the entire instance data
2004 together with the CRC signature to the FS I/O data mapper as shown in 10.2.3.1.
2005 Table A.4 shows Version "1" of the generic FS I/O data structure description for FS-Devices.
2006 With the help of this table, individual instances of FS-Device I/O Process Data can be created
2007 via IODD and, amongst others, used for an automatic mapping of IO-Link Safety data to FSCP
2008 safety data.
2009 Table A.4 – Generic FS I/O data structure description
Item name Item length Definition
IO_DescVersion 1 octet Version of this generic structure description: 0x01

InputDataRange 1 octet Length in octets of the entire FS input Process Data including the
3 or 5 octets respectively for the safety code (Control/Status and
CRC-16/32)
TotalOfInBits 1 octet Number of the entire set of input BooleanT (bits)
TotalOfInOctets 1 octet Number of octets with input BooleanT (including unfilled octets)
TotalOfInInt16 1 octet Number of input IntegerT(16)
TotalOfInInt32 1 octet Number of input IntegerT(32)
OutputDataRange 1 octet Length in octets of the entire FS output Process Data including
the 3 or 5 octets respectively for the safety code (Control/Status
and CRC-16/32)
TotalOfOutBits 1 octet Number of the entire set of output BooleanT (bits)
TotalOfOutOctets 1 octet Number of octets with output BooleanT (including unfilled octets)
TotalOfOutInt16 1 octet Number of output IntegerT(16)
TotalOfOutInt32 1 octet Number of output IntegerT(32)
FSP_IO_StructCRC 2 octets CRC-16 signature value across all items (see Annex D.1)
2010
2011 Figure A.1 shows the instance of the FS I/O data description of the example in Figure A.2.
2012 IO_DESCVERSION 01 0x01

INPUT_DATA_RANGE 07 0x07
2013 TOTAL_OF_INBITS 13 0x0D
TOTAL_OF_INOCTETS 02 0x02
2014 TOTAL_OF_ININT16 01 0x01
TOTAL_OF_ININT32 00 0x00
OUTPUT_DATA_RANGE 03 0x03
2015 TOTAL_OF_OUTBITS 00 0x00
TOTAL_OF_OUTOCTETS 00 0x00
2016 TOTAL_OF_OUTINT16 00 0x00
TOTAL_OF_OUTINT32 00 0x00
2017 FSP_IO_STRUCTCRC 2386 0x0952
2018 Figure A.1 – Instance of an FS I/O data description
2019 Figure A.2 shows an example with FS input Process Data and no FS output Process Data.
Transmission
direction Boolean octet 1 Boolean octet 2 MSO LSO 3 octets
Non-safety
1 1 0 1 1 0 0 1 0 0 0 1 1 0 0 1 IntegerT(16) Safety code
data
Padding bits
Number of Boolean octets: 2 Number of IntegerT(16): 1

Number of Booleans: 13
2020
2021 Figure A.2 – Example FS I/O data structure with non-safety data
2022 A.2.10 FS_Password

2023 It is the responsibility of the FS-Master and FS-Master Tool designer to define the password
2024 mechanism (e.g. setting/resetting, encryption, protection against easy capturing via line
2025 monitors). Maximum size is 32 octets. Encoding shall be ASCII. A mix of upper/lower case
2026 characters, numbers, and special characters shall be possible.
2027 A.2.11 Reset_FS_Password

2028 With the help of this password, a reset to factory settings of the FS-Device can be performed
2029 including FS_Password. New commissioning can take place with FSP_TechParCRC = "0"
2030 (see A.2.7).
2031 A.2.12 FSP_ParamDescCRC

2032 This dummy parameter within the IODD contains the CRC signature calculated across the
2033 entire parameter descriptions within the IODD according to the algorithm specified in E.5. The
2034 CRC-16 in Table D.1 shall be used. A seed value "0" shall be used since leading "0"
2035 parameter values cannot occur (see D.3.6).
2036 The purpose of this parameter is to secure the relevant descriptions of safety parameters
2037 within the IODD against data falsification during storage and handling as shown in Figure A.3
FS-Master
tool
Proprietary
FS-Master
IO-Link
communication Protocol Technology
parameter parameter
IODD IOPD
"Dedicated
FSP_AuthentCRC, Tool"
FS- FSP_ProtParCRC,
…
Device
FSP_ParamDescCRC
2038
2039 Figure A.3 – Securing of safety parameters
2040
2041 Annex B
2042 (normative, non-safety related)
2043
2044 Extensions to EventCodes
2045 B.1 Additional EventCodes
2046 The Safety Communication Layer (SCL) can create its own EventCodes as shown in Table
2047 B.1.
2048 Table B.1 – SCL specific EventCodes
EventCode Defnition and recommended maintenance action FS-Device TYPE

status value
0xB000 Transmission error (CRC signature) 2 Warning

0xB001 Transmission error (Counter) 2 Warning
0xB002 Transmission error (Timeout) 3 Error
0xB003 Unexpected authentication code 3 Error
0xB004 Unexpected authentication port 3 Error
0xB005 Incorrect FSP_AuthentCRC 3 Error
0xB006 Incorrect FSP_ProtParCRC 3 Error
0xB007 Incorrect FSP_TechParCRC 3 Error
0xB008 Incorrect FSP_IO_StructCRC 3 Error
0xB009 Watchdog time out of specification (e.g. "0") 3 Error
0xB00A Reserved: do not use number; do not evaluate number - -
2049
2050 Usually, "CRC signature" and/or "Counter" transmission errors are caused by seriously
2051 falsified IO-Link messages with SPDUs due to heavy interferences. There is nothing to repair
2052 and an operator acknowledgment is sufficient. This very unlikely warning should inform the
2053 operator and the responsible production manager about possible changes within a machine
2054 requiring an inspection according to the safety manual (see H.6).
2055 Annex C
2056 (normative, safety related)
2057
2058 Extensions to Data Types
2059 C.1 Data types for IO-Link Safety
2060 Table C.1 shows the available data types in IO-Link Safety (see 11.4.7.2).
2061 Table C.1 – Data types for IO-Link Safety
Data type Coding Length See [1] Device example
BooleanT/bit BooleanT ("packed form" for efficien- 1 bit Clause E.2.2; Table Proximity switch
cy, no WORD structures); assignment E.22 and Figure E.8
of signal names to bits is possible.
IntegerT(16) IntegerT (enumerated or signed) 2 octets Clause E.2.4; Table Protection fields of
E.4, E.7 and Figure laser scanner
E.2
IntegerT(32) IntegerT (enumerated or signed) 4 octets Clause E.2.4; Table Encoder or length
E.4, E.6, and Figure measurement (≈ ±
E.2 2 km, resolution 1
µm)
2062
2063 C.2 BooleanT (bit)

2064 A BooleanT represents a data type that can have only two different values i.e. TRUE and
2065 FALSE. The data type is specified in Table C.2.
2066 Table C.2 – BooleanT for IO-Link Safety
Data type name Value range Resolution Length
BooleanT TRUE / FALSE - 1 bit
2067
2068 IO-Link Safety uses solely the so-called packed form via RecordT as shown in Table C.3.
2069 Table C.3 – Example of BooleanT within a RecordT
Subindex Offset Data items Data Type Name/symbol
1 0 TRUE BooleanT Proximity_1

2 1 FALSE BooleanT Proximity_2
3 2 FALSE BooleanT EmergencyStop_1
4 3 TRUE BooleanT EmergencyStop_2
5 4 TRUE BooleanT EmergencyStop_3
2070
2071 Figure C.1 demonstrates an example of a BooleanT data structure. Padding bits are "0".
Transmission Padding bits ("0") Bit 0

direction
0 0 0 1 1 0 0 1
Bit offset: 7 6 5 4 3 2 1 0
2072
2073 Figure C.1 – Example of a BooleanT data structure

2074 Only RecordT data structures of 8 bit length are permitted. Longer data structures shall use
2075 multiple RecordT data structures (see Annex C.5).
2076 NOTE Data structures longer than 8 bit can cause mapping problems with upper level FSCP systems (see 3.4.2)
2077 C.3 IntegerT (16)

2078 An IntegerT(16) is representing a signed number depicted by 16 bits. The number is
2079 accommodated within the octet container 2 and right-aligned and extended correctly signed to
2080 the chosen number of bits. The data type is specified in Table C.4 for singular use. SN
2081 represents the sign with "0" for all positive numbers and zero, and "1" for all negative
2082 numbers. Padding bits are filled with the content of the sign bit (SN).
2083 Table C.4 – IntegerT(16)
IntegerT(16) -2 15 to 2 15 - 1 1 2 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 C.5).
2084
2085 The coding of IntegerT(16) is shown in Table C.5.
2086 Table C.5 – IntegerT(16) coding
Bit 7 6 5 4 3 2 1 0 Container
Octet 1 SN 2 14 2 13 2 12 2 11 2 10 29 28 2 octets
Octet 2 27 26 25 24 23 22 21 20
2087
2088 C.4 IntegerT (32)

2089 An IntegerT(32) is representing a signed number depicted by 32 bits. The number is
2090 accommodated within the octet container 4 and right-aligned and extended correctly signed to
2091 the chosen number of bits. The data type is specified in Table C.6 for singular use. SN
2092 represents the sign with "0" for all positive numbers and zero, and "1" for all negative
2093 numbers. Padding bits are filled with the content of the sign bit (SN).
2094 Table C.6 – IntegerT(32)
IntegerT(32) -2 31 to 2 31 - 1 1 4 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 C.7).
2095
2096 The coding of IntegerT(32) is shown in Table C.7
2097 Table C.7 – IntegerT(32) coding
Bit 7 6 5 4 3 2 1 0 Container
Octet 1 SN 2 30 2 29 2 28 2 27 2 26 2 25 2 24 4 octets
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
2098 C.5 Safety Code

2099 Size of the Safety Code as shown in Figure C.2 and Figure C.3 can be identified by the
2100 • Parameter "FSP_ProtMode" (see Table A.1), and

2101 • FS I/O structure description (see Table A.1).
2102 Thus, the overall I/O data structure can be identified even if there are non-safety related I/O
2103 data associated with the SPDU.
From FS-Master:
CRC signature Control&MCnt FS-PDout
Signature across
Including 0 to 4 octets, or
FS-Output data
3 bit counter 0 to 26 octets
and Control & counting
2/4 octets 1 octet 4/26 octets
Safety code
2104
2105 Figure C.2 – Safety Code of an output message
From FS-Device:
FS-PDin Status&DCnt CRC signature
Including Signature across

0 to 4 octets, or FS-Input data
3 bit counter
0 to 26 octets and Status & counting mirror
inverted
4/26 octets 1 octet 2/4 octets
Safety code
2106
2107 Figure C.3 – Safety Code of an input message
2108
2109 Annex D
2111
2112 CRC generator polynomials
2113
2114 D.1 Overview of CRC generator polynomials

2115 Hamming distance and properness for all required data lengths are important characteristics
2116 to select a particular generator polynomial.
2117 If the generator polynomial g(x) = p(x)*(1 + x) is used, where p(x) is a primitive polynomial of
2118 degree (r – 1), then the maximum total block length is 2 (r – 1) - 1, and the code is able to
2119 detect single, double, triple and any odd number of errors (see [19]).
2120 If properness is approved, the residual error probability for the approved data length is 2 -r .
2121 It shall be prohibited that the CRC generator polynomial used in the underlying transmission
2122 systems, for example IO-Link, matches the CRC generator polynomial used for IO-Link
2123 Safety.
2124 Table D.1 shows the CRC-16 and CRC-32 generator polynomials in use for IO-Link Safety:
2125 Table D.1 – CRC generator polynomials for IO-Link Safety
CRC-16/32 polynomial Data length Hamming Properness Reference Remark

("Normal" representation) (bits) distance
0x4EAB ≤ 128 ≥6 ≤ 7 octets [20] Suitable for

functional
0xF4ACFB13 ≤ 32768 ≥6 ≤128 octets [20] safety
≤ 65534 ≥4
NOTE Representation: "Normal": high order bit omitted
2126
2127 The CRC-16 can be used
2128 • to secure cyclic Process Data exchange with a total safety PDU length of up to 7 octets,
2129 i.e. 4 octets for safety Process Data and
2130 • to secure the transfer of up to 16 octets of FSP parameters at start-up or restart.
2131
2132 The CRC-32 can be used
2133 • to secure cyclic Process Data exchange with a total safety PDU length of up to 32 octets,
2134 i.e. 27 octets for safety Process Data and
2135 • to secure the transfer and data integrity of the entire FST parameter set.
2136 Additional parameters and assumptions for the calculation of residual error probabilities/rates
2137 can be found in 11.4.6.
2138 D.2 Residual error probabilities

2139 Figure D.1 shows the results of residual error probability (REP) calculations over bit error
2140 probabilities (BEP) for safety PDU lengths from 3 to 7 octets.
2141 The REP is less than 0,9×10 -9 for BEPs less than the required 10 -2 at a length of 7 octets.
REP
2-16
10-2
CRC-16 generator polynomial: 0x4EAB

Residual error probability
0,9×10-9 (n = 7 octets)
Safety PDU lengths n
n = 7 octets n = 3 octets
Bit error probability

2142
2143 Figure D.1 – CRC-16 generator polynomial
2144 Figure D.2 shows the results of residual error probability (REP) calculations over bit error
2145 probabilities (BEP) for safety PDU lengths from 5 to 128 octets.
2146 The REP is less than 0,5×10 -10 for BEPs less than the required 10 -2 at a length of 26 octets.
REP
10-2
2-32
Residual error probability
0,5×10-10 (n = 26 octets)
CRC-32 generator polynomial: 0xF4ACFB13
Safety PDU lengths n
n = 128 octets n = 5 octets
BEP
Bit error probability
2147
2148 Figure D.2 – CRC-32 generator polynomial

2149 D.3 Implementation considerations

2150 D.3.1 Overview
2151 The designer has two choices to implement the CRC signature calculation. One is based on
2152 an algorithm using XOR and shift operations while the other is faster using octet shifts and
2153 lookup tables.
2154 D.3.2 Bit shift algorithm (16 bit)

2155 For the 16-bit CRC signature, the value 0x4EAB is used as the generator polynomial. The
2156 number of data bits may be odd or even. The value generated after the last octet corresponds
2157 to the CRC signature to be transferred.
2158 Figure D.3 shows the algorithm for the innermost loop in "C" programming language.
2159
void crc16_calc(unsigned char x, unsigned long *r)
2160 int i;
for (i = 1; i <= 8; i++)
2161 if ((bool)(*r & 0x8000) != (bool)(x & 0x80))
/* XOR = 1  shift and process polynomial */
2162 *r = (*r << 1) ^ 0x4EAB;
else
2163 /* XOR = 0  shift only */
*r = *r << 1;
2164 x = x << 1;
/* for */
2165
2166 Figure D.3 – Bit shift algorithm in "C" language (16 bit)
2167 The variables used in Figure D.3 are specified in Table D.2.
2168 Table D.2 – Definition of variables used in Figure D.3
Variable Definition
x Data bits including 16 bit CRC signature with "0"

*r Dereferenced pointer to CRC signature
i Bitcount 1 to 8
2169
2170 D.3.3 Lookup table (16 bit)

2171 The corresponding function in "C" language is shown in Figure D.4. This function is faster.
2172 However, the lookup table requires memory space.
2173
r = crctab16 [((r >> 8) ^ *q++) & 0xff] ^(r << 8)
2174
2175 Figure D.4 – CRC-16 signature calculation using a lookup table
Variable Definition
r CRC signature
q q represents the pointer to the actual octet value requiring CRC calculation. After
reading the value this pointer shall be incremented for the next octet via q++.
2178
2179 The function in Figure D.4 uses the lookup in Table D.4.
2180 Table D.4 – Lookup table for CRC-16 signature calculation
CRC-16 lookup table (0 to 255)
0000 4EAB 9D56 D3FD 7407 3AAC E951 A7FA

E80E A6A5 7558 3BF3 9C09 D2A2 015F 4FF4
9EB7 D01C 03E1 4D4A EAB0 A41B 77E6 394D
76B9 3812 EBEF A544 02BE 4C15 9FE8 D143
73C5 3D6E EE93 A038 07C2 4969 9A94 D43F
9BCB D560 069D 4836 EFCC A167 729A 3C31
ED72 A3D9 7024 3E8F 9975 D7DE 0423 4A88
057C 4BD7 982A D681 717B 3FD0 EC2D A286
E78A A921 7ADC 3477 938D DD26 0EDB 4070
0F84 412F 92D2 DC79 7B83 3528 E6D5 A87E
793D 3796 E46B AAC0 0D3A 4391 906C DEC7
9133 DF98 0C65 42CE E534 AB9F 7862 36C9
944F DAE4 0919 47B2 E048 AEE3 7D1E 33B5
7C41 32EA E117 AFBC 0846 46ED 9510 DBBB
0AF8 4453 97AE D905 7EFF 3054 E3A9 AD02
E2F6 AC5D 7FA0 310B 96F1 D85A 0BA7 450C
81BF CF14 1CE9 5242 F5B8 BB13 68EE 2645
69B1 271A F4E7 BA4C 1DB6 531D 80E0 CE4B
1F08 51A3 825E CCF5 6B0F 25A4 F659 B8F2
F706 B9AD 6A50 24FB 8301 CDAA 1E57 50FC
F27A BCD1 6F2C 2187 867D C8D6 1B2B 5580
1A74 54DF 8722 C989 6E73 20D8 F325 BD8E
6CCD 2266 F19B BF30 18CA 5661 859C CB37
84C3 CA68 1995 573E F0C4 BE6F 6D92 2339
6635 289E FB63 B5C8 1232 5C99 8F64 C1CF
8E3B C090 136D 5DC6 FA3C B497 676A 29C1
F882 B629 65D4 2B7F 8C85 C22E 11D3 5F78
108C 5E27 8DDA C371 648B 2A20 F9DD B776
15F0 5B5B 88A6 C60D 61F7 2F5C FCA1 B20A
FDFE B355 60A8 2E03 89F9 C752 14AF 5A04
8B47 C5EC 1611 58BA FF40 B1EB 6216 2CBD
6349 2DE2 FE1F B0B4 174E 59E5 8A18 C4B3
NOTE This table contains 16 bit values in hexadecimal representation for each value (0 to 255) of the argument a
in the function crctab16 [a]. The table should be used in ascending order from top left (0) to bottom right (255).
2181
2182 D.3.4 Bit shift algorithm (32 bit)

2183 For the 32-bit CRC signature, the value 0xF4ACFB13 is used as the generator polynomial.
2184 The number of data bits may be odd or even. The value generated after the last octet
2185 corresponds to the CRC signature to be transferred.
2186 Figure D.5 shows the algorithm for the innermost loop in "C" programming language.
2187
2188
2189
void crc32_calc(unsigned char x, unsigned long *r)
int i;
2190
for (i = 1; i <= 8; i++)
2191 if ((bool)(*r & 0x80000000) != (bool)(x & 0x80))
/* XOR = 1  shift and process polynomial */
2192 *r = (*r << 1) ^ 0xF4ACFB13;
else
2193 /* XOR = 0  shift only */
*r = *r << 1;
2194 x = x << 1;
/* for */
2195
2196 Figure D.5 – Bit shift algorithm in "C" language (32 bit)
Variable Definition
x Data bits including 32 bit CRC signature with "0"

*r Dereferenced pointer to CRC signature
i Bit count 1 to 8
2199
2200 D.3.5 Lookup table (32 bit)

2201 The corresponding function in "C" language is shown in Figure D.6. This function is faster.
2202 However, the lookup table requires memory space.
2203
r = crctab32 [((r >> 24) ^ *q++) & 0xff] ^(r << 8)
2204
2205 Figure D.6 – CRC-32 signature calculation using a lookup table
Variable Definition
r CRC signature
q q represents the pointer to the actual octet value requiring CRC calculation. After
reading the value this pointer shall be incremented for the next octet via q++.
2208
2209 The function in Figure D.6 uses the lookup table in Table D.7.
2210 Table D.7 – Lookup table for CRC-32 signature calculation
00000000 F4ACFB13 1DF50D35 E959F626 3BEA1A6A CF46E179 261F175F D2B3EC4C

77D434D4 8378CFC7 6A2139E1 9E8DC2F2 4C3E2EBE B892D5AD 51CB238B A567D898
EFA869A8 1B0492BB F25D649D 06F19F8E D44273C2 20EE88D1 C9B77EF7 3D1B85E4
987C5D7C 6CD0A66F 85895049 7125AB5A A3964716 573ABC05 BE634A23 4ACFB130
2BFC2843 DF50D350 36092576 C2A5DE65 10163229 E4BAC93A 0DE33F1C F94FC40F
5C281C97 A884E784 41DD11A2 B571EAB1 67C206FD 936EFDEE 7A370BC8 8E9BF0DB
C45441EB 30F8BAF8 D9A14CDE 2D0DB7CD FFBE5B81 0B12A092 E24B56B4 16E7ADA7

B380753F 472C8E2C AE75780A 5AD98319 886A6F55 7CC69446 959F6260 61339973
57F85086 A354AB95 4A0D5DB3 BEA1A6A0 6C124AEC 98BEB1FF 71E747D9 854BBCCA
202C6452 D4809F41 3DD96967 C9759274 1BC67E38 EF6A852B 0633730D F29F881E
B850392E 4CFCC23D A5A5341B 5109CF08 83BA2344 7716D857 9E4F2E71 6AE3D562
CF840DFA 3B28F6E9 D27100CF 26DDFBDC F46E1790 00C2EC83 E99B1AA5 1D37E1B6
7C0478C5 88A883D6 61F175F0 955D8EE3 47EE62AF B34299BC 5A1B6F9A AEB79489
0BD04C11 FF7CB702 16254124 E289BA37 303A567B C496AD68 2DCF5B4E D963A05D
93AC116D 6700EA7E 8E591C58 7AF5E74B A8460B07 5CEAF014 B5B30632 411FFD21
E47825B9 10D4DEAA F98D288C 0D21D39F DF923FD3 2B3EC4C0 C26732E6 36CBC9F5
AFF0A10C 5B5C5A1F B205AC39 46A9572A 941ABB66 60B64075 89EFB653 7D434D40
D82495D8 2C886ECB C5D198ED 317D63FE E3CE8FB2 176274A1 FE3B8287 0A977994
4058C8A4 B4F433B7 5DADC591 A9013E82 7BB2D2CE 8F1E29DD 6647DFFB 92EB24E8
378CFC70 C3200763 2A79F145 DED50A56 0C66E61A F8CA1D09 1193EB2F E53F103C
840C894F 70A0725C 99F9847A 6D557F69 BFE69325 4B4A6836 A2139E10 56BF6503
F3D8BD9B 07744688 EE2DB0AE 1A814BBD C832A7F1 3C9E5CE2 D5C7AAC4 216B51D7
6BA4E0E7 9F081BF4 7651EDD2 82FD16C1 504EFA8D A4E2019E 4DBBF7B8 B9170CAB
1C70D433 E8DC2F20 0185D906 F5292215 279ACE59 D336354A 3A6FC36C CEC3387F
F808F18A 0CA40A99 E5FDFCBF 115107AC C3E2EBE0 374E10F3 DE17E6D5 2ABB1DC6
8FDCC55E 7B703E4D 9229C86B 66853378 B436DF34 409A2427 A9C3D201 5D6F2912
17A09822 E30C6331 0A559517 FEF96E04 2C4A8248 D8E6795B 31BF8F7D C513746E
6074ACF6 94D857E5 7D81A1C3 892D5AD0 5B9EB69C AF324D8F 466BBBA9 B2C740BA
D3F4D9C9 275822DA CE01D4FC 3AAD2FEF E81EC3A3 1CB238B0 F5EBCE96 01473585
A420ED1D 508C160E B9D5E028 4D791B3B 9FCAF777 6B660C64 823FFA42 76930151
3C5CB061 C8F04B72 21A9BD54 D5054647 07B6AA0B F31A5118 1A43A73E EEEF5C2D
4B8884B5 BF247FA6 567D8980 A2D17293 70629EDF 84CE65CC 6D9793EA 993B68F9
NOTE This table contains 32 bit values in hexadecimal representation for each value (0 to 255) of the argument a
in the function crctab32 [a]. The table should be used in ascending order from top left (0) to bottom right (255).
2211
2212 D.3.6 Seed values

2213 The algorithm for example in Figure D.3 does not mention explicitly any initial value for the
2214 CRC signature variable in "*r". It is implicitly assumed to be "0" by default. This initial value is
2215 sometimes called "seed value" in literature.
2216 In 11.4.6 a seed value of "1" is required for the cyclic data exchange of safety PDUs. The
2217 reason for that is the possibility for the FS-PDout or FS-PDin data to become completely "0".
2218 Since it is a property of CRC-signatures for leading zeros in data strings not to be secured by
2219 CRC signatures whenever the seed value is "0", the requirement in 11.4.6 is justified. Any
2220 value instead of "0" could be used. However, a "1" is sufficient and faster since all of the
2221 operations then are shifting and only the last one consists of shifting and XOR processing.
2222 In A.2.3, A.2.8, A.2.9, A.2.12, and E.5.1, the seed value can be "0" since there are no leading
2223 zeros within the data strings.
2224 Annex E
2226
2227 IODD extensions
2228
2229 E.1 General

2230 The IODD of FS-Devices requires extensions for particular FSP parameters and a securing
2231 mechanism to protect the content of IODD files from being falsified as mentioned in 11.7.1.
2232 In addition, some of the parameters specified in [1] shall be mandatory instead of optional for
2233 this profile (see E.3).
2234 E.2 Schema

2235 There are no extensions required to the existing IODD schema specified in [9].
2236 E.3 IODD constraints

2237 E.3.1 Overview and general rules
2238 Table E.1 shows the constrained Index assignments of data objects (parameters) for IO-Link
2239 Safety.
2240 As a general rule, all parameters with Read/Write (R/W) access shall provide a default value
2241 within the IODD (for FSP parameters see E.5.2).
2242 Table E.1 – Constrained Index assignment of data objects for IO-Link Safety
Index Object Access Length Data type M/O/ Definition/remark

(dec) name C
…
0x0001 Direct R/W RecordT - Direct Parameter Page 2 shall not be used
(1) Parameter as well as DirectParameterOverlays
Page 2
0x0002 System W 1 octet UIntegerT M Command code definition as specified in
(2) Command B.2.2 in [1] and in E.3.2 in this document
…
0x000D Profile R variable ArrayT of M Profile characteristic as specified in B.2.5
(13) Charac- UIntegerT16 in [1] and in E.3.3 in this document
teristic
0x000E PDInput R variable ArrayT of M As specified in B.2.6 in [1] and in E.3.4 in
(14) Descriptor OctetStringT3 this document
0x000F PDOutput R variable ArrayT of M As specified in B.2.7 in [1] and in E.3.4 in
(15) Descriptor OctetStringT3 this document
…
0x0013 Product ID R max. 64 StringT M As specified in B.2.11 in [1]
(19) octets
0x0015 Serial- R max. 16 StringT M As specified in B.2.13 in [1]
(21) Number octets
0x0016 Hardware R max. 64 StringT M As specified in B.2.14 in [1]
(22) Revision octets
0x0017 Firmware R max. 64 StringT M As specified in B.2.15 in [1]
(23) Revision octets
0x0018 Application R/W Min. 16, StringT M As specified in B.2.16 in [1]
(24) Specific max. 32
Tag octets
…
Index Object Access Length Data type M/O/ Definition/remark

(dec) name C
0x0020 Error R 2 octets UIntegerT M As specified in B.2.17 in [1]

(32) Count
…
0x0024 Device R 1 octet UIntegerT M As specified in B.2.18 in [1]
(36) Status
0x0025 Detailed R variable ArrayT of M As specified in B.2.19 in [1]
(37) Device OctetStringT3
Status
…
0x0028 Process- R PD Device specific C As specified in B.2.20 in [1], if PDin
(40) DataInput length available. See E.3.4.
0x0029 Process- R PD Device specific C As specified in B.2.21 in [1], if PDout
(41) DataOutput length available. See E.3.4.
…
0x4000- Profile See Table A.1
0x4FFF specific
(16384- Index
20479)
…
Key M = mandatory; O = optional; C = conditional
2243
2244 E.3.2 Specific SystemCommands

2245 Table E.2 shows the specific behavior of the SystemCommand "Restore factory settings" in
2246 FS-Devices.
2247 Table E.2 – Specific behavior of "Restore factory settings"
Command Command Command name M/O Definition

(hex) (dec)
…
0x82 130 Restore factory settings M This command shall only be effective
whenever the parameter value of
FSP_TechParCRC is "0" (commissioning
phase)
…
Key M = mandatory; O = optional
2248
2249 E.3.3 Profile Characteristic

2250 The ProfileID for IO-Link Safety is 32800 or 0x8020.
2251 E.3.4 ProcessDataInput and ProcessDataOutput

2252 Only the references are required in case of PDin or PDout. This description can be omitted if
2253 there is only Safety Code to be transmitted. The sample IODD in E.5.7 shows details.
2254 E.4 IODD conventions

2255 E.4.1 Naming
2256 While this document and [1] use "parameter" for any data object of a Device and FS-Device,
2257 IODDs in [9] use "variable" instead and thus all those data objects are indicated via the prefix
2258 "V_". The following rules apply:
2259 1) Naming of non-safety parameters shall be "V_xxx". Prefixes "V_FSP", "V_FST" shall
2260 be omitted for FS-Devices.
2261 2) Naming of FST technology safety parameters shall be "V_FST_xxx".

2262 3) Naming of FSP safety parameters shall be "V_FSP_xxx".
2263 These namings conventions shall only be used for IO-Link Safety.
2264
2265 E.4.2 Process Data (PD)

2266 The following rules apply for Process Data:
2267 1) PDin and PDout shall be described as record.
2268 2) Subindices shall be used within the records to differentiate between safety PD and
2269 non-safety PD.
2270 3) Subindices 1 to 126 shall be used to describe safety PD starting with the highest bit
2271 offset.
2272 4) Safety Code (see C.5) shall not be described in detail within the IODD. However,
2273 Subindex 127 shall be used to describe the Safety Code by means of an OctetStringT
2274 (3 or 5 octets) as a dummy to indicate the length of the Safety Code.
2275 5) Subindices 128 to 255 shall be used to describe non-safety PD.
2276 6) Multiple PD structure definitions selected by conditions are not permitted.
2277
2278 E.4.3 IODD conventions for user interface

2279 The following rules apply for user interface:
2280 1) The IODD shall contain different headlines (menu IDs) for the parameter block types
2281 "Standard", "FST", and "FSP" in this order.
2282 2) The following abbreviations shall be used for the user role menu IDs: Observer ("OR"),
2283 Maintenance ("MR"), Specialist ("SR").
2284
2285 The menu IDs shall be structured and named as follows:
2286 "ME_OR_Param_Standard"
2287 "ME_MR_Param_Standard"
2288 "ME_SR_Param_Standard"
2289 "ME_OR_Param_FST"
2290 "ME_MR_Param_FST"
2291 "ME_SR_Param_FST"
2292 "ME_OR_Param_FSP"
2293 "ME_MR_Param_FSP"
2294 "ME_SR_Param_FSP"
2295
2296 Menus can be omitted for example in case of the observer role. They can be referen-
2297 ced multiple if for example the same menu is used for the maintenance role and the
2298 specialist role.
2299
2300 E.4.4 Master Tool features

2301 The following rules on how to present the IODD to the user are highly recommended:
2302 1) IODD interpreter in Master Tools should show headlines not only for PDin and PDout
2303 but also for safety and non-safety PD. These headlines should use yellow colors.
2304 2) In case of PD observation via ISDU access the variable names should be the same as
2305 with cyclic PDs.
2306
2307 E.5 Securing

2308 E.5.1 General
2309 An IODD-based non-safety viewer calculates this 32 bit CRC signature across the FSP
2310 parameter description within the IODD. The algorithm for the calculation is shown in this
2311 Annex. The safety-related interpreter of the FS-Master Tool checks the correctness of the
2312 imported IODD data. Parameter names associated to Index/Subindex are known in the FS
2313 IODD interpreter and can be checked in a safe manner.
2314 An IODD checker is not safety-related and thus not sufficient.
2315 Only one IODD per DeviceID is permitted. A particular FS-Device (hardware) can have two
2316 DeviceIDs for example a current DeviceID and a DeviceID of a previous software version.
2317 Figure E.1 shows the algorithm to build the FSP_ParamDescCRC signature. The algorithm
2318 shall be used across the Authenticity and the Protocol block (see Table A.1). A seed value "0"
2319 shall be used (see D.3.6).
1. General rule: All numerical values are serialized in big-endian octet order (most
significant octet first).
2. Serialize the Index (16 bit unsigned integer) of the FS parameter.
3. Serialize the bitLength (16 bit unsigned integer) of the RecordT.
4. Sort the RecordItems in ascending order by Subindex.
5. For each RecordItem (including the last one) serialize:
a) The Subindex (8 bit unsigned integer)
b) The bitOffset (16 bit unsigned integer)
c) The Datatype (8 bit unsigned integer): 1=UIntegerT(8), 2=UIntegerT(16),
3=UIntegerT(32)
d) If and only if a DefaultValue is given in the IODD: The DefaultValue (8/16/32 bit
unsigned integer according to Datatype).
e) If and only if SingleValues or a ValueRange is given in the IODD: The allowed
values. A list of SingleValues is serialized as a sequence of these values, in
ascending order. A ValueRange is serialized by the sequence of the minimum and
maximum value. Whether SingleValues and/or a ValueRange are allowed depends
on the specific RecordItem. See Table E.4.
6. Calculate the 2 octet CRC across the octet stream using the CRC polynomial 0x4EAB.
2320
2321 Figure E.1 – Algorithm to build the FSP parameter CRC signatures
2322 E.5.2 DefaultValues for FSP

2323 The DefaultValues for FSP_Authenticity1/2, FSP_Port, FSP_AuthentCRC, FSP_TechParCRC,
2324 and FSP_ProtParCRC shall be "0". Table E.3 demonstrates the user actions to replace the
2325 default values by actual values.
2326 Table E.3 – User actions to replace DefaultValues
Parameter User actions
FSP_Authenticity1/2 During commissioning, the Authenticity values can be acquired from the gateway
and displayed by the Master Tool. SCL will not start with the default value.
FSP_Port The user shall replace the default "0" by an allowed number with the help of the
Master Tool during commissioning. SCL will not start with the default value.
FSP_AuthentCRC Master Tool calculates this CRC signature
Parameter User actions
FSP_TechParCRC The user parameterizes the FS-Device during commissioning or maintenance and
uses a Dedicated Tool to calculate the actual value (see 11.7.8 and 11.7.9)
FSP_ProtParCRC Master Tool calculates this CRC signature
2327
2328 E.5.3 FSP_Authenticity

2329 The values of the authenticity parameters cannot be defined within the IODD. They are
2330 maintained by the FS-Master Tool.
2331 E.5.4 FSP_Protocol

2332 The limited variability of the protocol parameters requires the securing mechanism specified
2333 in E.5.1.
2334 Table E.4 lists the RecordItems of FSP_Protocol to be serialized.
2335 Table E.4 – RecordItems of FSP_Protocol where allowed values shall be serialized
RecordItem Serialized as
FSP_ProtVersion List of 8-bit unsigned integer containing the allowed values, in ascending order
FSP_ProtMode List of 8-bit unsigned integer containing the allowed values, in ascending order
FSP_Watchdog Minimum value and maximum value of the contiguous range of allowed values
Any other All values according to the data type are allowed, therefore nothing is serialized
2336
2337 E.5.5 FSP_IO_Description

2338 The FSP_IO_Description parameters do not need a particular securing mechanism since
2339 these instance values are straight forward. The IODD designer can calculate the CRC
2340 signature already and place it into the IODD (see A.2.9).
2341 E.5.6 Sample serialization for FSP_ParamDescCRC
2342 Table E.5 shows a sample serialization for the calculation of the FSP_ParamDescCRC
2343 signature in E.5.7. A seed value "0" shall be used since there are no leading zeros (see
2344 D.3.6).
2345 Table E.5 – Sample serialization for FSP_ParamDescCRC
Offset Serialization IODD items Expected values
0000 42 00 index 42 00 (≠ 0)
0002 00 58 bitLength of index 00 58
0004 01 subindex 01 (Authenticity 1)
0005 00 38 bitOffset 00 38
0007 03 xsi:type=UIntegerT, bitLength=32 03
0008 00 00 00 00 RecordItemInfo/@defaultValue 00 00 00 00
000C 02 subindex 02 (Authenticity 2)
000D 00 18 bitOffset 00 18
000F 03 xsi:type=UIntegerT, bitLength=32 03
0010 00 00 00 00 RecordItemInfo/@defaultValue 00 00 00 00
0014 03 subindex 03 (Port)
0015 00 10 bitOffset 00 10
0018 00 RecordItemInfo/@defaultValue 00
0019 04 subindex 04 (AuthentCRC)
Offset Serialization IODD items Expected values
001A 00 00 bitOffset 00 00
001C 02 xsi:type=UIntegerT, bitLength=16 02
001D 00 00 RecordItemInfo/@defaultValue 00 00 (Dummy CRC)
001F 42 01 index 42 01
0021 00 60 bitLength of index 00 60
0023 01 subindex 01 (ProtVersion)
0024 00 58 bitOffset 00 58
0027 01 RecordItemInfo/@defaultValue 01
0028 01 SingleValue/@value 01 (example:16 bit)
0029 02 subindex 02 (ProtMode)
002A 00 50 bitOffset 00 50
002D 01 RecordItemInfo/@defaultValue Vendor defined
002E 01 SingleValue/@value 01
002F 03 subindex 03 (Watchdog)
0030 00 40 bitOffset 00 40
0033 00 64 RecordItemInfo/@defaultValue (Vendor defined)
0035 00 64 ValueRange/@lowerValue 00 64 (example: 100)
0037 13 88 ValueRange/@upperValue 13 88 (example: 5000)
0039 04 subindex 04 (IO_StructCRC)
003A 00 30 bitOffset 00 30
003D 09 52 RecordItemInfo/@defaultValue (see A.2.9) (Vendor defined)
003F 05 Subindex 05 (TechParCRC)
0040 00 10 bitOffset 00 10
0043 00 00 00 00 RecordItemInfo/@defaultValue 00 00 00 00 (Vendor)
0047 06 subindex 06 (ProtParCRC)
0048 00 00 bitOffset 00 00
004A 02 xsi:type=UIntegerT, bitLength=16 02
004B 00 00 RecordItemInfo/@defaultValue 00 00 Dummy CRC
Calculated FSP_ParamDescCRC signature value is: 7520 (0x1D60) See E.5.7
2346
2347 The sample serialization in Table E.5 shows 77 octets to be secured via the CRC-16
2348 polynomial listed in Table D.1. This is only sufficient due to the fact that most of the values
2349 are expected values within the FS-Master Tool importing the IODD. Only a few values are
2350 variable and "Vendor defined" and require securing (see offsets: 0028, 002D,0033 to 0037,
2351 003D, and 0043). The remaining values can be compared with preset values.
2352 The "Dummy CRC" are placeholders to be replaced by the FS-Master Tool once the user
2353 assigned the actual parameter values.
2354
2355 E.5.7 FST and FSP parameters and Data Storage

2356 FST parameters shall be described within the IODD. A "packed" parameter transfer via one
2357 ISDU that is not described within the IODD is possible for Data Storage as long as the result
2358 in the Device/FS-Device is the same as with discrete ISDUs (see 11.7.6). A manufacturer-
2359 /vendor is responsible to guarantee this behavior.
2360 FSP parameters (authenticity and protocol) shall be described within the IODD also and are
2361 part of Data Storage.
2362 E.5.8 Sample IODD of an FS-Device

2363 The following XML code represents the sample code of an FS-Device IODD. A complete IODD
2364 file with name IO-Link-SafetyDevice-20170225-IODD1.1.xml can be downloaded from the IO-
2365 Link websites.
2366 This sample IODD contains already calculated CRC signature values:
2367 <?xml version="1.0" encoding="UTF-8"?>
2368 <IODevice xmlns="http://www.io-link.com/IODD/2010/10" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2369 xsi:schemaLocation="http://www.io-link.com/IODD/2010/10 IODD1.1.xsd">
2370 <DocumentInfo copyright="IO-Link Community" releaseDate="2017-02-25" version="V1.0"/>
2371 <ProfileHeader>
2372 <ProfileIdentification>IO Device Profile</ProfileIdentification>
2373 <ProfileRevision>1.1</ProfileRevision>
2374 <ProfileName>Device Profile for IO Devices</ProfileName>
2375 <ProfileSource>IO-Link Consortium</ProfileSource>
2376 <ProfileClassID>Device</ProfileClassID>
2377 <ISO15745Reference>
2378 <ISO15745Part>1</ISO15745Part>
2379 <ISO15745Edition>1</ISO15745Edition>
2380 <ProfileTechnology>IODD</ProfileTechnology>
2381 </ISO15745Reference>
2382 </ProfileHeader>
2383 <ProfileBody>
2384 <DeviceIdentity deviceId="160" vendorId="65535" vendorName="IO-Link Community">
2385 <VendorText textId="T_VendorText"/>
2386 <VendorUrl textId="T_VendorUrl"/>
2387 <VendorLogo name="IO-Link-logo.png"/>
2388 <DeviceName textId="T_DeviceName"/>
2389 <DeviceFamily textId="T_DeviceFamily"/>
2390 <DeviceVariantCollection>
2391 <DeviceVariant productId="SafetyDeviceVariant" deviceIcon="IO-Link-SafetyDevice-icon.png" deviceSymbol="IO-Link-
2392 SafetyDevice-pic.png">
2393 <Name textId="TN_SafetyDeviceVariant"/>
2394 <Description textId="TD_SafetyDeviceVariant"/>
2395 </DeviceVariant>
2396 </DeviceVariantCollection>
2397 </DeviceIdentity>
2398 <DeviceFunction>
2399 <Features blockParameter="true" dataStorage="true" profileCharacteristic="32800">
2400 <SupportedAccessLocks parameter="true" dataStorage="true" localParameterization="false" localUserInterface="false"/>
2401 </Features>
2402 <DatatypeCollection>
2403 
2404 <Datatype id="D_FSP_Authenticity" xsi:type="RecordT" bitLength="88">
2405 <RecordItem subindex="1" bitOffset="56">
2406 <SimpleDatatype xsi:type="UIntegerT" bitLength="32"/>
2407 <Name textId="TN_FSCP_Authenticity_1"/>
2408 <Description textId="TD_FSCP_Authenticity_1"/>
2409 </RecordItem>
2412 <Name textId="TN_FSCP_Authenticity_2"/>
2413 <Description textId="TD_FSCP_Authenticity_2"/>
2414 </RecordItem>
2417 <Name textId="TN_FSP_Port"/>
2418 <Description textId="TD_FSP_Port"/>
2419 </RecordItem>
2422 <Name textId="TN_FSP_AuthentCRC"/>
2423 <Description textId="TD_FSP_AuthentCRC"/>
2424 </RecordItem>
2425 </Datatype>
2426 <Datatype id="D_FSP_Password" xsi:type="StringT" fixedLength="32" encoding="US-ASCII"/>
2427 </DatatypeCollection>
2428 <VariableCollection>
2429 <StdVariableRef id="V_DirectParameters_1"/>
2430 
2431 <StdVariableRef id="V_DirectParameters_2"/>
2432 
2433 <StdVariableRef id="V_SystemCommand">
2434 
2435 <StdSingleValueRef value="130"/>
2436 
2437 </StdVariableRef>
2438 <StdVariableRef id="V_DeviceAccessLocks">
2439 
2440 <StdRecordItemRef subindex="1" defaultValue="false"/>
2441 
2442 <StdRecordItemRef subindex="2" defaultValue="false"/>
2443 
2444 </StdVariableRef>
2445 <StdVariableRef id="V_VendorName" defaultValue="IO-Link Community"/>
2446 
2447 <StdVariableRef id="V_VendorText" defaultValue="http://www.io-link.com"/>
2448 
2449 <StdVariableRef id="V_ProductName" defaultValue="SafetyDevice"/>
2450 
2451 <StdVariableRef id="V_ProductID" defaultValue="SafetyDeviceVariant"/>
2452 
2453 <StdVariableRef id="V_ProductText" defaultValue="Sample IO-Link Safety"/>
2454 
2455 <StdVariableRef id="V_SerialNumber"/>
2456 
2457 <StdVariableRef id="V_HardwareRevision"/>
2458 
2459 <StdVariableRef id="V_FirmwareRevision"/>
2460 
2461 <StdVariableRef id="V_ApplicationSpecificTag" defaultValue="IO-Link Safety"/>
2462 
2463 <StdVariableRef id="V_ErrorCount"/>
2464 
2465 <StdVariableRef id="V_DeviceStatus"/>
2466 
2467 <StdVariableRef id="V_DetailedDeviceStatus" fixedLengthRestriction="8"/>
2468 
2469 <StdVariableRef id="V_ProcessDataInput"/>
2470 
2471 
2472 
2473 <Variable index="64" id="V_NonSafetyParameter" accessRights="rw">
2474 <Datatype xsi:type="IntegerT" bitLength="16"/>
2475 <Name textId="TN_NonSafetyParameter"/>
2476 </Variable>
2477 
2478 <Variable index="65" id="V_FST_DiscrepancyTime" accessRights="rw" defaultValue="0">
2479 <Datatype xsi:type="UIntegerT" bitLength="16"/>
2480 <Name textId="TN_FST_DiscrepancyTime"/>
2481 </Variable>
2482 <Variable index="66" id="V_FST_Filter" accessRights="rw" defaultValue="0">
2484 <Name textId="TN_FST_Filter"/>
2485 </Variable>
2486 
2487 <Variable index="16896" id="V_FSP_Authenticity" accessRights="rw">
2488 <DatatypeRef datatypeId="D_FSP_Authenticity"/>
2489 <RecordItemInfo subindex="1" defaultValue="0"/>
2490 
2492 
2494 
2496 
2497 <Name textId="TN_FSP_Authenticity"/>
2498 <Description textId="TD_FSP_Authenticity"/>
2499 </Variable>
2500 <Variable index="16897" id="V_FSP_Protocol" accessRights="rw">
2501 <Datatype xsi:type="RecordT" bitLength="96">

2503 <SimpleDatatype xsi:type="UIntegerT" bitLength="8">
2504 <SingleValue value="0"/>
2505 
2506 </SimpleDatatype>
2507 <Name textId="TN_FSP_ProtVer"/>
2508 <Description textId="TD_FSP_ProtVer"/>
2509 </RecordItem>
2512 
2513 <SingleValue value="1"/>
2514 
2515 
2517 <Name textId="TN_FSP_ProtMode"/>
2518 <Description textId="TD_FSP_ProtMode"/>
2519 </RecordItem>
2522 
2523 <ValueRange lowerValue="100" upperValue="5000"/>
2525 <Name textId="TN_FSP_Watchdog"/>
2526 <Description textId="TD_FSP_Watchdog"/>
2527 </RecordItem>
2530 <Name textId="TN_FSP_IO_StructCRC"/>
2531 <Description textId="TD_FSP_IO_StructCRC"/>
2532 </RecordItem>
2535 <Name textId="TN_FSP_TechParCRC"/>
2536 <Description textId="TD_FSP_TechParCRC"/>
2537 </RecordItem>
2540 <Name textId="TN_FSP_ProtParCRC"/>
2541 <Description textId="TD_FSP_ProtParCRC"/>
2542 </RecordItem>
2543 </Datatype>
2545 
2547 
2549 
2551 
2552 
2554 
2556 
2557 <Name textId="TN_FSP_Protocol"/>
2558 <Description textId="TD_FSP_Protocol"/>
2559 </Variable>
2560 <Variable index="16912" id="V_FSP_Password" accessRights="wo">
2561 <DatatypeRef datatypeId="D_FSP_Password"/>
2562 <Name textId="TN_FSP_Password"/>
2563 <Description textId="TD_FSP_Password"/>
2564 </Variable>
2565 <Variable index="16913" id="V_FSP_Reset_Password" accessRights="wo">
2566 <DatatypeRef datatypeId="D_FSP_Password"/>
2567 <Name textId="TN_FSP_Reset_Password"/>
2568 <Description textId="TD_FSP_Reset_Password"/>
2569 </Variable>
2570 <Variable index="16914" id="V_FSP_ParamDescCRC" accessRights="ro" defaultValue="444">
2571 
2573 <Name textId="TN_FSP_ParamDescCRC"/>
2574 <Description textId="TD_FSP_ParamDescCRC"/>
2575 </Variable>
2576 </VariableCollection>
2577 <ProcessDataCollection>
2578 
2579 <ProcessData id="P_ProcessData">
2580 <ProcessDataIn bitLength="88" id="PI_ProcessDataIn">
2581 
2583 
2585 <SimpleDatatype xsi:type="BooleanT"/>
2586 <Name textId="TN_PDin-Bool1"/>
2587 </RecordItem>
2591 </RecordItem>
2595 </RecordItem>
2599 </RecordItem>
2603 </RecordItem>
2607 </RecordItem>
2611 </RecordItem>
2615 </RecordItem>
2616 
2617 
2621 </RecordItem>
2625 </RecordItem>
2629 </RecordItem>
2633 </RecordItem>
2637 </RecordItem>
2638 
2640 <SimpleDatatype xsi:type="IntegerT" bitLength="16"/>
2641 <Name textId="TN_PDin-Int1"/>
2642 </RecordItem>
2643 
2645 <SimpleDatatype xsi:type="OctetStringT" fixedLength="3"/>
2646 <Name textId="TN_PD_FSTrailer"/>
2647 <Description textId="TD_PD_FSTrailer"/>
2648 </RecordItem>
2649 
2650 
2653 <Name textId="TN_PD_Rev"/>
2654 <Description textId="TD_PD_Rev"/>
2655 </RecordItem>
2656 </Datatype>
2657 <Name textId="TN_ProcessDataIn"/>
2658 </ProcessDataIn>
2659 <ProcessDataOut bitLength="24" id="PO_ProcessDataOut">
2661 
2663 <SimpleDatatype xsi:type="OctetStringT" fixedLength="3"/>
2664 <Name textId="TN_PD_FSTrailer"/>
2665 <Description textId="TD_PD_FSTrailer"/>
2666 </RecordItem>
2667 </Datatype>
2668 <Name textId="TN_ProcessDataOut"/>
2669 </ProcessDataOut>
2670 </ProcessData>
2671 </ProcessDataCollection>
2672 <EventCollection>
2673 
2674 <Event code="45056" type="Warning">
2675 <Name textId="TN_TransmissionError_CRCSignature"/>
2676 </Event>
2677 <Event code="45057" type="Warning">
2678 <Name textId="TN_TransmissionError_Counter"/>
2679 </Event>
2680 <Event code="45058" type="Error">
2681 <Name textId="TN_TransmissionError_Timeout"/>
2682 </Event>
2684 <Name textId="TN_UnexpectedAuthenticationCode"/>
2685 </Event>
2687 <Name textId="TN_UnexpectedAuthenticationPort"/>
2688 </Event>
2690 <Name textId="TN_IncorrectFSP_AuthentCRC"/>
2691 </Event>
2693 <Name textId="TN_IncorrectFSP_ProtParCRC"/>
2694 </Event>
2696 <Name textId="TN_IncorrectFSP_TechParCRC"/>
2697 </Event>
2699 <Name textId="TN_IncorrectFSP_IO_StructCRC"/>
2700 </Event>
2702 <Name textId="TN_WatchdogTimeOutOfSpec"/>
2703 </Event>
2705 
2706 <Name textId="TN_Event1"/>
2707 </Event>
2710 <Name textId="TN_Event2"/>
2711 </Event>
2712 </EventCollection>
2713 <UserInterface>
2714 <MenuCollection>
2715 <Menu id="M_Identification">
2716 <VariableRef variableId="V_VendorName"/>
2717 <VariableRef variableId="V_VendorText"/>
2718 <VariableRef variableId="V_ProductName"/>
2719 <VariableRef variableId="V_ProductID"/>
2720 <VariableRef variableId="V_ProductText"/>
2721 <VariableRef variableId="V_SerialNumber"/>
2722 <VariableRef variableId="V_HardwareRevision"/>
2723 <VariableRef variableId="V_FirmwareRevision"/>
2724 </Menu>
2725 <Menu id="M_OR_Parameter">
2726 <RecordItemRef variableId="V_DeviceAccessLocks" subindex="1" accessRightRestriction="ro"/>
2727 <VariableRef variableId="V_ApplicationSpecificTag"/>
2728 <VariableRef variableId="V_NonSafetyParameter" accessRightRestriction="ro"/>
2729 </Menu>
2730 <Menu id="M_MR_Param_Standard">
2731 <Name textId="TN_MR_Param_Standard"/>
2732 <RecordItemRef variableId="V_DeviceAccessLocks" subindex="1"/>

2734 <VariableRef variableId="V_NonSafetyParameter"/>
2735 </Menu>
2736 <Menu id="M_MR_Param_FST">
2737 <Name textId="TN_MR_Param_FST"/>
2738 <VariableRef variableId="V_FST_DiscrepancyTime" unitCode="1056" accessRightRestriction="ro"/>
2739 <VariableRef variableId="V_FST_Filter" unitCode="1056" accessRightRestriction="ro"/>
2740 </Menu>
2741 <Menu id="M_MR_Param_FSP">
2742 <Name textId="TN_MR_Param_FSP"/>
2743 <VariableRef variableId="V_FSP_Authenticity" accessRightRestriction="ro"/>
2744 <VariableRef variableId="V_FSP_Protocol" accessRightRestriction="ro"/>
2745 </Menu>
2746 <Menu id="M_SR_Param_Standard">
2747 <Name textId="TN_SR_Param_Standard"/>
2748 <RecordItemRef variableId="V_DeviceAccessLocks" subindex="1"/>
2750 <VariableRef variableId="V_NonSafetyParameter"/>
2751 </Menu>
2752 <Menu id="M_SR_Param_FST">
2753 <Name textId="TN_SR_Param_FST"/>
2754 <VariableRef variableId="V_FST_DiscrepancyTime" unitCode="1056"/>
2755 <VariableRef variableId="V_FST_Filter" unitCode="1056"/>
2756 </Menu>
2757 <Menu id="M_SR_Param_FSP">
2758 <Name textId="TN_SR_Param_FSP"/>
2759 <VariableRef variableId="V_FSP_Authenticity"/>
2760 <VariableRef variableId="V_FSP_Protocol"/>
2761 <VariableRef variableId="V_FSP_Password"/>
2762 <VariableRef variableId="V_FSP_Reset_Password"/>
2763 </Menu>
2764 <Menu id="M_MR_Parameter">
2765 <MenuRef menuId="M_MR_Param_Standard"/>
2766 <MenuRef menuId="M_MR_Param_FST"/>
2767 <MenuRef menuId="M_MR_Param_FSP"/>
2768 </Menu>
2769 <Menu id="M_SR_Parameter">
2770 <MenuRef menuId="M_SR_Param_Standard"/>
2771 <MenuRef menuId="M_SR_Param_FST"/>
2772 <MenuRef menuId="M_SR_Param_FSP"/>
2773 </Menu>
2774 <Menu id="M_StandardProcessData">
2775 <Name textId="TN_StandardProcessData"/>
2776 <RecordItemRef variableId="V_ProcessDataInput" subindex="128"/>
2777 </Menu>
2778 <Menu id="M_FS_ProcessData">
2779 <Name textId="TN_FS_ProcessData"/>
2794 </Menu>
2795 <Menu id="M_Observation">
2796 <MenuRef menuId="M_StandardProcessData"/>
2797 <MenuRef menuId="M_FS_ProcessData"/>
2798 </Menu>
2799 <Menu id="M_Diagnosis">
2800 <VariableRef variableId="V_ErrorCount"/>
2801 <VariableRef variableId="V_DeviceStatus"/>
2802 <VariableRef variableId="V_DetailedDeviceStatus"/>
2803 </Menu>
2804 </MenuCollection>
2805 <ObserverRoleMenuSet>
2806 <IdentificationMenu menuId="M_Identification"/>
2807 <ParameterMenu menuId="M_OR_Parameter"/>
2808 <ObservationMenu menuId="M_Observation"/>
2809 <DiagnosisMenu menuId="M_Diagnosis"/>

2810 </ObserverRoleMenuSet>
2811 <MaintenanceRoleMenuSet>
2813 <ParameterMenu menuId="M_MR_Parameter"/>
2816 </MaintenanceRoleMenuSet>
2817 <SpecialistRoleMenuSet>
2819 <ParameterMenu menuId="M_SR_Parameter"/>
2822 </SpecialistRoleMenuSet>
2823 </UserInterface>
2824 </DeviceFunction>
2825 </ProfileBody>
2826 <CommNetworkProfile xsi:type="IOLinkCommNetworkProfileT" iolinkRevision="V1.1">
2827 <TransportLayers>
2828 <PhysicalLayer bitrate="COM3" minCycleTime="2000" sioSupported="true" mSequenceCapability="43">
2829 <Connection xsi:type="M12-4ConnectionT" connectionSymbol="IO-Link-SafetyDevice-con-pic.png">
2830 <ProductRef productId="SafetyDeviceVariant"/>
2831 <Wire1 function="L+"/>
2832 <Wire2 function="Other"/>
2833 <Wire3 function="L-"/>
2834 <Wire4 function="C/Q"/>
2835 </Connection>
2836 </PhysicalLayer>
2837 </TransportLayers>
2838 <Test>
2839 <Config1 index="64" testValue="0x55,0x99"/>
2840 <Config2 index="1024" testValue="0x00"/>
2841 <Config3 index="24" testValue="0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20,0x20"/>
2842 <Config7 index="155">
2843 <EventTrigger disappearValue="2" appearValue="1"/>
2844 <EventTrigger disappearValue="4" appearValue="3"/>
2845 </Config7>
2846 </Test>
2847 </CommNetworkProfile>
2848 <ExternalTextCollection>
2849 <PrimaryLanguage xml:lang="en">
2850 <Text id="T_VendorText" value="Breakthrough in Communication"/>
2851 <Text id="T_VendorUrl" value="http://www.io-link.com"/>
2852 <Text id="T_DeviceName" value="Safety Device"/>
2853 <Text id="T_DeviceFamily" value="Safety Device Family"/>
2854 <Text id="TN_SafetyDeviceVariant" value="Safety Device"/>
2855 <Text id="TD_SafetyDeviceVariant" value="Sample for a device with IO-Link Safety"/>
2856 
2857 <Text id="TN_NonSafetyParameter" value="Sample Parameter"/>
2858 
2859 <Text id="TN_FST_DiscrepancyTime" value="Discrepancy Time"/>
2860 <Text id="TN_FST_Filter" value="Filter"/>
2861 
2862 <Text id="TN_FSP_Authenticity" value="Authenticity"/>
2863 <Text id="TD_FSP_Authenticity" value="Authenticity parameters"/>
2864 <Text id="TN_FSCP_Authenticity_1" value="FSCP_Authenticity_1"/>
2865 <Text id="TD_FSCP_Authenticity_1" value=""A-Code" from the upper level FSCP system"/>
2866 <Text id="TN_FSCP_Authenticity_2" value="FSCP_Authenticity_2"/>
2867 <Text id="TD_FSCP_Authenticity_2" value="Extended "A-Code" from the upper level FSCP system"/>
2868 <Text id="TN_FSP_Port" value="FSP_Port"/>
2869 <Text id="TD_FSP_Port" value="PortNumber identifiying the particular FS-Device"/>
2870 <Text id="TN_FSP_AuthentCRC" value="FSP_AuthentCRC"/>
2871 <Text id="TD_FSP_AuthentCRC" value="CRC-16 across authenticity parameters"/>
2872 <Text id="TN_FSP_Protocol" value="Protocol"/>
2873 <Text id="TD_FSP_Protocol" value="Protocol parameters"/>
2874 <Text id="TN_FSP_ProtVer" value="FSP_ProtVer"/>
2875 <Text id="TD_FSP_ProtVer" value="Protocol version (0=current version)"/>
2876 <Text id="TN_FSP_ProtMode" value="FSP_ProtMode"/>
2877 <Text id="TD_FSP_ProtMode" value="Protocol mode (1=16 bit CRC, 2=32 bit CRC)"/>
2878 <Text id="TN_FSP_Watchdog" value="FSP_Watchdog"/>
2879 <Text id="TD_FSP_Watchdog" value="Monitoring of IO update"/>
2880 <Text id="TN_FSP_IO_StructCRC" value="FSP_IO_StructCRC"/>
2881 <Text id="TD_FSP_IO_StructCRC" value="CRC-16 across IO structure description block"/>
2882 <Text id="TN_FSP_TechParCRC" value="FSP_TechParCRC"/>
2883 <Text id="TD_FSP_TechParCRC" value="Securing code across FST (technology specific parameter)"/>
2884 <Text id="TN_FSP_ProtParCRC" value="FSP_ProtParCRC"/>
2885 <Text id="TD_FSP_ProtParCRC" value="CRC-16 across protocol parameters"/>
2886 <Text id="TN_FSP_Password" value="FS_Password"/>

2887 <Text id="TD_FSP_Password" value="Password for the access protection of FSP parameter and Dedicated Tools"/>
2888 <Text id="TN_FSP_Reset_Password" value="Reset_FS_Password"/>
2889 <Text id="TD_FSP_Reset_Password" value="Password to reset the FST parameter to factory settings and to reset implicitly
2890 the FS-Password"/>
2891 <Text id="TN_FSP_ParamDescCRC" value="FSP_ParamDescCRC"/>
2892 <Text id="TD_FSP_ParamDescCRC" value="A dummy variable to store the CRC across the safety parameters within the
2893 IODD in the defaultValue"/>
2894 
2895 <Text id="TN_ProcessDataIn" value="Process Data In"/>
2896 <Text id="TN_PDin-Bool1" value="FS process data in Boolean 1"/>
2909 <Text id="TN_PDin-Int1" value="FS process data in Int 1"/>
2910 <Text id="TN_PD_FSTrailer" value="F-Message Trailer"/>
2911 <Text id="TD_PD_FSTrailer" value="Control/Status octet and CRC"/>
2912 <Text id="TN_PD_Rev" value="Revolutions"/>
2913 <Text id="TD_PD_Rev" value="Rotational speed"/>
2914 <Text id="TN_ProcessDataOut" value="Process Data Out"/>
2915 
2916 <Text id="TN_TransmissionError_CRCSignature" value="Transmission error (CRC signature)"/>
2917 <Text id="TN_TransmissionError_Counter" value="Transmission error (Counter)"/>
2918 <Text id="TN_TransmissionError_Timeout" value="Transmission error (Timeout)"/>
2919 <Text id="TN_UnexpectedAuthenticationCode" value="Unexpected authentication code"/>
2920 <Text id="TN_UnexpectedAuthenticationPort" value="Unexpected authentication port"/>
2921 <Text id="TN_IncorrectFSP_AuthentCRC" value="Incorrect FSP_AuthentCRC"/>
2922 <Text id="TN_IncorrectFSP_ProtParCRC" value="Incorrect FSP_ProtParCRC"/>
2923 <Text id="TN_IncorrectFSP_TechParCRC" value="Incorrect FSP_TechParCRC"/>
2924 <Text id="TN_IncorrectFSP_IO_StructCRC" value="Incorrect FSP_IO_StructCRC"/>
2925 <Text id="TN_WatchdogTimeOutOfSpec" value="Watchdog time out of specification"/>
2926 
2927 <Text id="TN_MR_Param_Standard" value="Standard (non-safety) parameter"/>
2928 <Text id="TN_MR_Param_FST" value="Fail-safe technology parameter"/>
2929 <Text id="TN_MR_Param_FSP" value="Fail-safe protocol parameter"/>
2930 <Text id="TN_SR_Param_Standard" value="Standard (non-safety) parameter"/>
2931 <Text id="TN_SR_Param_FST" value="Fail-safe technology parameter"/>
2932 <Text id="TN_SR_Param_FSP" value="Fail-safe protocol parameter"/>
2933 <Text id="TN_StandardProcessData" value="Standard (non-safety) process data in"/>
2934 <Text id="TN_FS_ProcessData" value="Fail-safe process data in"/>
2936 <Text id="TN_Event1" value="Event 1"/>
2937 <Text id="TN_Event2" value="Event 2"/>
2938 </PrimaryLanguage>
2939 </ExternalTextCollection>
2940 <Stamp crc="1946410459">
2941 <Checker name="IODD-Checker V1.1.3" version="V1.1.3.0"/>
2942 </Stamp>
2943 </IODevice>
2944
2945
2946 Annex F
2947 (normative, non-safety related)
2948
2949 Device Tool Interface (DTI) for IO-Link
2950
2951 F.1 Purpose of DTI

2952 For integration of IO-Link Devices in a Master Tool, IODD files shall be used provided by the
2953 Device manufacturer. Syntax and semantics of these files are standardized (see [9]) such that
2954 the Devices can be integrated independently from the vendor/manufacturer.
2955 However, some applications/standards such as functional safety require a so-called

2956 Dedicated Tool for e.g. parameter setting and validation, at least as a complement to the
2957 IODD method. This Dedicated Tool shall communicate with its Device and is responsible for
2958 the data integrity according to [3]. In the following, the term "Device Tool" is used within this
2959 document. Without any additional standardized technology, such an IO-Link system would
2960 force the user
2961 • to know which Device Tool is required for a particular Device,

2962 • to enter the communication parameters of the Device both in the Master Tool and in the
2963 Device Tool and to keep the parameters consistent,
2964 • to store consistent configuration and parameterization data from both the Master Tool and
2965 the Device Tool at one single place to archive project data.
2966 In addition, it would face the Device manufacturer
2967 • with the necessity to implement the communication functionality for each supported field
2968 bus system, and
2969 • with the problem of nested communication whenever the target Device is located in a
2970 different network and only a proprietary gateway interconnects the networks..
2971 A solution is the Device Tool Interface (DTI) technology specified herein after. It can be used
2972 for safety (FS-Master/FS-Device) as well as for non-safety (Master/Device) IO-Link devices.
2973 F.2 Base model

2974 The Device Tool Interface (DTI) comprises three main parts according to Figure 59:
2975 • An invocation interface between Master Tool and Device Tool

2976 • A backward interface between Master Tool and Device Tool ("Backchannel")
2977 • A communication interface between Device Tool and a Communication Server
2978 The combination of these three parts leads to the following user interaction.
2979 A Master Tool is supposed to be already installed on a PC running Microsoft Windows

2980 operating system. A Device is configured with the help of the corresponding IODD file of the
2981 Device manufacturer. This step includes assignment of port addresses and adjustment of the
2982 Device parameters defined in the IODD.
2983 Now, the DTI standard allows for associating Device Tool identification with IO-Link Device
2984 identification. The Master Tool uses DTI specific mechanisms to find the Device Tool for a
2985 given Device. It provides for example in the context menu of a selected Device an entry that
2986 can be used to invoke the Device Tool. As soon as the Device Tool is active, it identifies the
2987 selected Device. The user can instantly establish a communication with the Device without
2988 entering address information and alike and assign parameter values. Assigned values can be
2989 returned to the Master Tool using the Backchannel.
2990 For the communication server part, DTI relies on technology specified in [17]. DTI comprises
2991 mechanisms to store and maintain Device data objects (project data).
2992 F.3 Invocation interface

2993 F.3.1 Overview
2994 The invocation interface is used to transfer information from the representation of the Device
2995 in the Master Tool to the Device Tool. In order to achieve a high flexibility and to be able to
2996 identify different versions of the interface, both the description of the Device Tool capabilities
2997 and the invocation parameters are stored in XML based documents. For the assignment from
2998 Master Tool to Device Tool the system registry of the Microsoft Windows operating system is
2999 used.
3000 Figure F.1 shows the principle of the DTI invocation interface part.
Provided by Device manufacturer
IODD PID
(including Program Interface Device Tool/
SDCI_Device_ Description Dedicated Tool
Identification and ("Tool.xml") ("Tool.exe")
communication Describes supported
parameter) IOPD tool functions
2 6 5
Install Read Delete Read
1
TPF
3 Temporary Parameter File
Invoke
Device Tool
Master Tool (~923tmp.xml)
Create
4
Performed by
Master Tool
3001
3002 Figure F.1 – Principle of DTI invocation interface
3003 Precondition for the mechanism is the availability of the Master Tool and all used Device
3004 Tools on one and the same PC.
3005 For the Tool invocation the following steps are required:
3006 (1) As usual, the IODD file is imported into the Master Tool. The Device is configured and
3007 communication settings are made. With the help of (SDCI) Device Identification data the
3008 Master Tool is able to find the installed Device Tool and the directory path to the "Program
3009 Interface Description" (PID) file. Annex F.3.2 describes this procedure in detail.
3010 (2) The Master Tool reads the content of the PID file. This file contains information about the
3011 interface version and the supported Tool functions. The structure of the PID file is
3012 described in Annex F.3.3.
3013 (3) Before launching the Device Tool, the Master Tool creates a new "Temporary Parameter
3014 File" (TPF) that contains all invocation parameters. See F.3.4 for details.
3015 (4) The Master Tool launches the Device Tool and passes the name of the TPF. See F.3.4.
3016 (5) The Device Tool reads and interprets the content of the TPF file.
3017 (6) The Device Tool deletes the TPF file after processing. See F.3.4.
3018 F.3.2 Detection of Device Tool
3019 F.3.2.1 Registry structure
3020 In order for DTI to identify the type of an IO-Link Device, a specific, unique, and unambiguous
3021 "SDCI_Device_Identifier" is used in the PC system registry and within the Temporary Para-
3022 meter File (TPF).
3023 Figure F.2 shows the structure of the DTI part of the registry. Each class in the diagram
3024 represents a registry key. Each attribute in the diagram represents a string value of the
3025 registry key. The semantics of the attributes is defined in Table F.1 and Table F.2.
DTI
1 1
1 Devices
*
Device_Tools SDCI_Devices
FS_Devices
1 1
1 1..*
1..* VendorID
"xUUID" is used to assign a particular SDCI_
Device_Identifier to an installed Device Tool. SDCI_Device_Identifier
The term "xUUID" is a placeholder for a real
UUID, for example DeviceID
1 1
{1311C965-293B-4121-9148-55DF4AEA1C44}
1..*
1..*
tUUID 1..*
dUUID
ToolPath
PID file
3026
3027 Figure F.2 – Structure of the registry
3028 Since for an SDCI_Device_Identifier an unlimited number of "UUID" elements can be inserted,
3029 the Master Tool shall handle all Tools of these "UUID" elements.
3030 F.3.2.2 Device Tool specific registry entries

3031 Each version of a Device Tool is represented by one UUID in the system registry.
3032 The installation program of a Device Tool (32 bit or 64 bit) shall insert this UUID as key under
3033 its appropriate registry path:
3034 HKEY_LOCAL_MACHINE\SOFTWARE\IO-Link Community\DTI\Device_Tools or
3035 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\IO-Link Community\DTI\Device_Tools
3036 A Master Tool shall check both registry paths.
3037 Within this key, two attributes with string values shall be used:
3038 • "PIDfile", containing the absolute path and name of the installed PID file, and
3039 • "ToolPath", containing the absolute path and name of the executable Device Tool file
3040 including its file extension (.exe)
3041 Figure F.3 illustrates registry entries for SDCI Devices and Device Tools.
Devices or
FS-Devices
SDCI Device
Identifier
Matching
UUIDs
3042
3043 Figure F.3 – Example of a DTI registry

3044 If different versions of a Device Tool for the same Device type exist (same
3045 SDCI_Device_Identifier), each version requires a separate UUID in the registry. In the PID
3046 files of the Device Tools, different version information shall be provided in the attribute
3047 "ToolDescription" of the element "ToolDescription" (see Table F.1). This leads to multiple
3048 items in the context menu of the Master Tool, differing in the description text.
3049 NOTE The advantage of a separate entry of the “ToolPath” keyword is a simpler installation procedure for the
3050 Device Tool. It can install the PID file without a need to modify this file.
3051 The installation program of a Device Tool shall also insert each UUID as key under the
3052 registry path
3053 HKEY_LOCAL_MACHINE\SOFTWARE\IO-Link Community\DTI\SDCI Devices\<SDCI Device

3054 Identifier>
3055 IO-Link Devices are identified unambiguously via the following items:
3056 • VendorID (assigned by IO-Link Community)

3057 • DeviceID (assigned by Device/FS-Device manufacturer)
3058 This information is part of the IO-Link Device Description (IODD), which allows the Master
3059 Tool to work with the Device (data, parameter) without establishing an online connection to
3060 the Device. The IDs can be found at the following locations within an IODD:
3061 (1) //ISO15745Profile/ProfileBody/DeviceIdentity/@vendorId

3062 (2) //ISO15745Profile/ProfileBody/DeviceIdentity/@deviceId
3063 With the help of the registry, the Master Tool is able to read the required information about
3064 the Device Tool (in case of safety: Dedicated Tool). Location and structure for the entries
3065 shall be commonly agreed upon.
3066 All entries shall be provided by the Device Tool under the following registry path:
3067 HKEY_LOCAL_MACHINE\SOFTWARE\IO-Link Community\DTI\SDCI Devices
3068 Within this path one or more keys can be inserted with the following field structure:
3069 0xvvvv-0xdddddd
3070 The meaning of the fields is:
3071 vvvv: Four-character VendorID in hexadecimal coding
3072 dddddd: Six-character DeviceID in hexadecimal coding.
3073 The question mark character "?" can be used in the DeviceID as wildcard to replace one
3074 single character. The number of question marks is only limited by the size of the field. If
3075 wildcards are used, the Device Tool is responsible for the check whether it supports the
3076 selected object.
3077 The assignment to the Tool is made by a string value within this key. The UUID shall be used
3078 as name for the string value. The number of string values is not limited, which in turn means
3079 an unlimited number of Tools that can be assigned to the same Device.
3080 Examples for valid keys (see Figure F.3):
3081 0x0A99-0x00880D The Tool can be launched in the context of a Device with a DeviceID
3082 0x00880D from the vendor with the VendorID 0x0A99.
3083 0x0F3B-0x002B?? The Tool can be started in the context of Devices with a DeviceID in the
3084 range of 0x002B00 to 0x002BFF from the vendor with the VendorID
3085 0x0F3B.
3086 F.3.2.3 Processing of the Registry Data

3087 The installation program of the Device Tool is responsible to insert the keys in the system
3088 registry as defined in Annex F.3.2.2.
3089 Figure F.4 shows an activity diagram illustrating the detection of a Device Tool in the registry
3090 via "SDCI_Device_Identifier".
Get SDCI_Device_Identifier from IODD of

the selected device in the Master Tool
Read SDCI_Device_Identifier from

Registry "...\DTI\SDCI Devices\
Mask wildcards "?" [Another

SDCI_Device_Identifier
key in Registry]
[No match]
D1 D3
[Matching SDCI_Device_Identifier in IODD]
Read all UUIDs of key

"...\DTI\SDCI Devices\<SDCI_Device_Identifier>"
Detect PID file name from each key

"...\DTI\Device_Tools\UUID"
[No other key]
Store PIDfile names and ToolPaths
[Another
SDCI_Device_Identifier
key in Registry ] [No other key]
D2
3091
3092 Figure F.4 – Detection of a Device Tool in registry

3093 NOTE All registry keys in Figure F.4 are relative to the path HKEY_LOCAL_MACHINE\SOFTWARE\IO-Link
3094 Community
3095 In a first step, the Master Tool gets the SDCI Device Identifier from the IODD of the selected
3096 object in the Master Tool. Then all sub keys in the system registry path …DTI\SDCI Devices
3097 shall be compared with this SDCI Device Identifier. If a sub key matches (excepting
3098 wildcards), the UUID sub key of this key is used to find the PID file name in the registry path
3099 DTI\Device Tools\<UUID>. Since the same PID file name can be found in different locations in
3100 the registry, the context menu of the Master Tool shall only show the Device Tools with
3101 different PID file names. As a last step, the information in the PID file is used to build the
3102 menu items of the Master Tool (Figure F.5).
3103 F.3.3 Program Interface Description – PID

3104 F.3.3.1 General
3105 The Program Interface Description (PID) file describes the properties of the Device Tool and
3106 contains data which are required by the Master Tool to build menu items in its graphical user
3107 interface (GUI). The PID file is an XML document. The corresponding XML schema is defined
3108 in F.9.2. UTF-8 shall be used for character encoding.
3109 This PID file shall be provided by the manufacturer of a Device/Device Tool and installed by
3110 the installation program associated with the Device Tool. This installation program shall also
3111 insert the name and installation path in the system registry (see F.3.2).
3112 The PID file allows the Master Tool to extend its GUI menu structure by the name of the
3113 Device Tool such that the user is able to launch the Device Tool for example from the context
3114 menu of a selected Device as illustrated exemplary in Figure F.5.

Toplevel Vendor 1
-… Vendor 2
- Device bb V1.1.2
FSP_Safety-Level -…
FSP_TechParCRC 0x3AF2 …
Vendor n
Device Tool Configure THC Offline configuration - Device xxx V2.3.04
- Device yyy V1.3
- Device zzz V123
Online configuration
Technology parameters (FST)
Filter 26
Discrepancy 5 Menu contains items of the

Tool invocation. Text stems
Redundancy yes
from the PID file
Test cycle 3
3115
3116 Figure F.5 – Menu for Device Tool invocation
3117 F.3.3.2 Structure of the PID file

3118 The PID file is an XML based document and structured as described in Figure F.6.
1 ProgramInterface
1
1 1 1
DocumentInfo
Version
1
EntryPoints
1 1
General ConformanceClass
1
VendorName Name
1..*
EntryPoint
1 1 1
ID
1
1..* 1..* * 1..*
ToolDescription InvocationPrefix OptionalFeature InfoText
xml:lang Name Name xml:lang

ToolName EntryPointName
ToolDescription EntryPointDescription
3119
3120 Figure F.6 – Structure of the PID file
3121 The corresponding XML schema can be found in F.9.2. Namespace URI for this file is
3122 "http://www.io-link.com/DTI/2016/06/PID".
3123 The elements of Figure F.6 are specified in Table F.1. The column "SV" indicates the schema
3124 version a particular attribute has been introduced.
3125 Table F.1 – Description of PID file elements
Element Attribute Type M/O SV Description
ProgramInterface – – – 1.0 Root element

DocumentInfo Version xsd:string M 1.0 Contains the schema version of PID
interface definition. Also determines the
newest TPF version supported by this
tool.
The value shall comply with the
following regular expression: \d+(\.\d+)*
In this version, the string "1.1" shall be
used.
General VendorName xsd:string M 1.0 Contains the name of the Device
vendor
ToolDescription xml:lang xsd:language M 1.0 Defines the language of the text. The
"2-letter coding" or the "3-letter coding"
as defined in ISO 639 shall be used.
ToolName xsd:string M 1.0 Describes the function of the Device
Tool. This text shall be used to extend
the GUI menu items of the Master Tool.
Default element in English language
shall always be present.
ToolDescription xsd:string O 1.0 Contains a short description of the
Device Tool.
Invocation Prefix – – – 1.0 With this element, the command line
arguments of the called Device Tool
can be modified. If a Device Tool is
able to interpret different command line
arguments, usually a prefix is used to
define the semantic of an argument.
If an InvocationPrefix is present in the
PID file, the Master Tool shall insert a
blank character as delimiter between
the InvocationPrefix string and the file
name of the TPF.
To interpret the command line argument
as a file name for a DTI call, a Device
Tool shall be launched as follows:
DeviceTool.exe -i "c:\tmp\TPF01.xml"
In this case, the prefix "-i" shall be
entered in the PID file.
Name xsd:string O 1.0 Defines which command line prefix is
used when the tool is launched. If this
attribute is not present, only the file
name of the TPF is used as command
line argument.
NOTE Since the datatype "string" is
used, blank characters (ASCII 32 dec)
are allowed.
XML Entities are allowed and shall be
converted by the Master Tool.
ConformanceClass Name xsd:string M 1.0 Contains the name of the conformance
class (F.8.1). One of the following
values is allowed:
"C1", "C2", or "C3"
OptionalFeature Name xsd:string M 1.0 Name of the implemented feature of the
Master Tool as described in Table F.8.
EntryPoints – – – 1.0 This optional element shall be used, if a
Device Tool has more than one entry
point.
EntryPoint ID xsd:string M 1.0 This element represents an entry point
of the Device Tool. Entry points are
used to generate additional sub menu
items in the "ToolDescription" context
menu of the Master Tool. Using entry

points a Device Tool can provide direct
access to Tool specific views or
functions.
The attribute "ID" identifies an Entry-
Point. It shall be unique within a PID
file.
InfoText – – – 1.0 The element "InfoText" is used to
define language dependent text
information for description of the entry
point. This information can be used to
extend the GUI menu items of the
Master Tool. An InfoText element in
English language shall always be
present here.
xml:lang xsd:string M 1.0 Defines the language of the text. The
"2-letter coding" or the "3-letter coding"
as defined in ISO 639 shall be used.
EntryPointName xsd:string M 1.0 Describes the function of the entry
point. This text shall be used to extend
the GUI menu items of the Master Tool.
EntryPointDescription xsd:string O 1.0 Contains a short description of the
entry point.
3126
3127 F.3.3.3 Example PID file

3128 The following XML code shows an example content of a PID file with EntryPoints.
3130 <ProgramInterface xmlns="http://www.io-link.com/DTI/2017/02/PID" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
3131 xmlns:prim="http://www.io-link.com/DTI/2017/02/Primitives" xsi:schemaLocation="http://www.io-link.com/DTI/2017/02/PID
3132 iosafe_pid_schema_20170225.xsd">
3133 <DocumentInfo version="V1.0"/>
3134 <General vendorName="IO-LinkCompany">
3135 <ToolDescription name="Configure THC" description="IO-Link-16 Safety Device" lang="en"/>
3136 <ToolDescription name="Konfiguriere THC" description="IO-Link-16 Safety Device" lang="de"/>
3137 <InvocationPrefix name="/"/>
3138 </General>
3139 <EntryPoints>
3140 <EntryPoint id="1">
3141 <InfoText name="Offline Configuration" description="Offline Configuration" lang="en"/>
3142 <InfoText name="Offline Konfiguration" description="Offline Konfiguration" lang="de"/>
3143 </EntryPoint>
3144 <EntryPoint id="2">
3145 <InfoText name="Online Configuration" description="Online Configuration" lang="en"/>
3146 <InfoText name="Online Konfiguration" description="Online Konfiguration" lang="de"/>
3147 </EntryPoint>
3148 </EntryPoints>
3149 <ConformanceClass name="C3"/>
3150 </ProgramInterface>
3151 F.3.4 Temporary Parameter File – TPF

3153 Due to the large number of parameters to be transferred from the Master Tool to the Device
3154 Tool, a parameter transfer by command line arguments is not a good solution. The necessary
3155 syntax would become too complex to cover all aspects.
3156 Instead, all required parameters are included into an XML file, called Temporary Parameter
3157 File (TPF) by the Master Tool and thus, the name of the XML file is passed as the only
3158 command line argument. If the Device Tool requires a command line switch, this information
3159 can be extracted from the PID file. See "InvocationPrefix" in Table F.1 for details.
3160 The XML schema for the TPF is defined in F.9.3. For character encoding, UTF-8 shall be
3161 used. The Master Tool shall use the newest TPF schema version supported by both the
3162 Master Tool and the Device Tool.
3163 After the TPF is interpreted, the Device Tool shall delete the TPF file.
3164 F.3.4.2 Structure of a TPF

3165 The structure of the TPF is defined by the XML schema shown in F.9.3. This schema is built
3166 in a generic manner, which means, a new parameter does not require the schema itself to be
3167 updated. Thus, new parameters can be introduced without a new definition of the TPF struc-
3168 ture.
3169 Namespace URI for this file is "http://www.io-link.com/DTI/2017/02/TPF".
3170 Figure F.7 shows the structure of a TPF.
1 ReturnInterfaceRequest 1
1
DocumentInfo
1
version 1
1
1
General DeviceItem VariableInstanceData
1..*
schemaPath vendorId
projectRelatedPath productId
1
portName deviceId
portId usedConfigFileCRC
1..*
masterName usedConfigFile
masterId reference Variable
displayNameES commReference
currentLanguage variableId
commServerProgID
busCategory 1
selectedEntryPoint
conformanceClass 1..*
Item
subindex
value
state
error
3171
3172 Figure F.7 – Structure of a TPF
3175 Table F.2 – Elements of a TPF
InvocationInterface – – M 1.0 Root element

DocumentInfo Version xsd:string M 1.0 Contains the schema version of the
TPF interface definition.
following regular expression:
\d+(\.\d+)*
One of the following values is
allowed:
"1.0" Used for TPF based on
version 1.0 schema files
General schemaPath xsd:string M 1.0 This attribute defines the path where
the schema files for FDT
communication schemas and
TPF/PID file are stored.
• This schema files shall be
installed on this path by the
Master Tool
• The path does not change during
runtime of the Master Tool
• The path can be used from a
Device Tool to initialize the XML

parser.
NOTE Even if no schema
validation is used, some XML
parsers need the location of the
schema files for initialization. In this
case, a Device Tool does not need
to install an own set of schema files
– it should use the schema files in
the path defined by this attribute.
projectRelatedPath xsd:string M 1.0 The attribute "ProjectRelatedPath"
contains information about a
directory which is assigned to the
project context of the Master Tool. A
Device Tool should use this path for
storage of its Device data. The
format and structure of this data is
defined by the Device Tool itself.
Within this directory, additional
subdirectories can be created.
The Master Tool is responsible to
keep all data in the directory tree in
its project context. That means, if
the project is copied or archived,
also this data shall be copied or
archived.
The attribute "ProjectRelatedPath"
contains a unique path (directory)
for each combination of Master
project and DTI Device Tool. For
example, different directories are
used for the same tool, if two Master
Tool projects are used. The file
name in "ProjectRelatedPath" shall
consist of the drive letter and an
absolute path expression.
Alternatively the UNC notation can
be used instead of the drive letter.
portName xsd:string M 1.0 Name of used FS-Master port
portId xsd:string M 1.0 ID of used FS-Master port 1 to n
masterName xsd:string M 1.0 User defined name of FS-Master
displayNameES xsd:string M 1.0 Display name of the Master Tool in
the language specified in attribute
"currentLanguage".
The Device Tool can use this name
in error messages or user dialogs to
provide more understandable texts.
currentLanguage xsd:string M 1.0 Defines which language shall be
used by the Device Tool for TPF.
The "2-letter coding" or the "3-letter
coding" as defined in ISO 639 can
be used.
If a Device Tool does not support
the selected language, the tool shall
use its default language.
commServerProgID xsd:string O 1.0 This attribute contains the ProgID of
the Communication Server provided
by the Master Tool manufacturer. It
allows the Device Tool to use the
Communication Server functionality.
See F.5.6 for details.
If this attribute is not provided, the
Master Tool does not support a
Communication Server.
busCategory xsd:string M 1.1 This attribute is used to specify the
used communication protocol. It also
can be used to find a corresponding
Communication Server.

Default value is "2C4CD8B8-D509-
4ECB-94A7-019F12569C8B"
selectedEntryPoint xsd:string O 1.0 Defines, which entry point of the
Device Tool was selected in the
Master Tool when the Device Tool
was launched. This attribute shall
contain only values defined in the
attribute "ID" of any element
"EntryPoint" of the corresponding
PID file.
This attribute allows the Device Tool
to show an entry point specific GUI
when it was launched.
If the PID file does not contain any
EntryPoint elements, this attribute
shall not be used in the TPF.
conformanceClass xsd:string M 1.0 Contains the name of the
conformance class of the Master
Tool. One of the following values is
allowed: "C2" or "C3". See Table
F.7.
DeviceItem vendorId xsd:string M 1.0 See Table B.1 in [1]
productId xsd:string M 1.0 See Table B.8 in [1]
deviceId xsd:string M 1.0 See Table B.1 in [1]
usedConfigFileCRC xsd:string M 1.0 IODD stamp
usedConfigFile xsd:string M 1.0 The keyword usedConfigFile con-
tains the file name of the used des-
cription file (e.g. IODD). The file
name shall consist of the drive
letter, an absolute path expression
and the file extension.
Alternatively the UNC notation can
be used instead of the drive letter.
The Device Tool It is not allowed to
modify the content of the description
file.
reference xsd:string M 1.0 Used to identify FS-Device within
engineering project
commReference xsd:string M 1.0 This attribute is used with the
Communication Server (CS) to
address a Device instance
unambiguously within the PC.
The unique nature of this attribute
shall be ensured by the Master Tool.
The structure of the attribute is only
defined by the Master Tool. It is not
allowed to interpret the syntax of
this keyword in the Device Tool.
LineFeed characters (ASCII 10 dec)
are not allowed in the string.
This attribute shall be provided for
all Device instances of a TPF, if the
Device Tool wants to use the CS
interface (Conformance Class 3
(C3)) and the commReference is
different from the DeviceReference.
VariableInstanceData – – M 1.0 Element "VariableInstanceData" is a
container for "Variable" elements (=
parameter).
Variable variableId xsd:string M 1.0 Contains the parameter ID
Item subindex xsd:string M 1.0 See [1]
value xsd:string M 1.0 Contains the parameter value.
In absence of a parameter-specific

rule for the representation of the
value: Numerical values shall use
the decimal coding without left-hand
zeros. Negative values shall have a
hyphen (ASCII 45 dec) prefix.
Separator for floating point values is
a dot (ASCII 46 dec). Other separa-
tors are not permitted.
state xsd:string M 1.0 Contains parameter status
error xsd:string M 1.0 Contains parameter error
3176
3177 F.3.4.3 Example of a TPF

3178 The following XML code shows the content of an exemplary TPF file.
3180 <InvocationInterface xmlns="http://www.io-link.com/DTI/2017/02/TPF" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
3181 instance" xmlns:prim="http://www.io-link.com/DTI/2017/02/Primitives" xsi:schemaLocation="http://www.io-
3182 link.com/DTI/2017/02/TPF IOsafe_TPF_Schema_20170225.xsd">
3183 <General currentLanguage="en" commServerProgID="DTI.MyCommunicationServer"
3184 projectRelatedPath="\\ServerName\ShareName\Projects" masterId="444444" masterName="CPU-1" portId="0" portName="P1-
3185 4" schemaPath="d:\dti\schema" displayNameEs="MyMTName" busCategory="IOLink" selectedEntryPoint="1"
3186 conformanceClass="C3"/>
3187 <DeviceItem reference="Project1/Network2/Device3/1897212" commReference="Controller3/Gateway7/Unit4" vendorId="335"
3188 deviceId="6553616" productId="SafetyDeviceVariant" usedConfigFile="d:\IODDfiles\IO-Link-SafetyDevice-20170225-
3189 IODD1.1.xml" usedConfigFileCRC="1946410459">
3190 <VariableInstanceData>
3191 <Variable variableId="V_DirectParameters_1">
3192 <Item subindex="0" state="empty" error="0" value=""/>
3197 <Item subindex="5" state="initial" error="0" value="17"/>
3208 </Variable>
3209 <Variable variableId="V_DeviceAccessLocks">
3210 <Item subindex="1" state="initial" error="0" value="false"/>
3212 </Variable>
3213 <Variable variableId="V_VendorName">
3214 <Item subindex="0" state="initial" error="0" value="IO-Link Community"/>
3215 </Variable>
3216 <Variable variableId="V_VendorText">
3217 <Item subindex="0" state="initial" error="0" value="http://www.io-link.com"/>
3218 </Variable>
3219 <Variable variableId="V_ProductName">
3220 <Item subindex="0" state="initial" error="0" value="SafetyDevice"/>
3221 </Variable>
3222 <Variable variableId="V_ProductID">
3223 <Item subindex="0" state="initial" error="0" value="SafetyDeviceVariant"/>
3224 </Variable>
3225 <Variable variableId="V_ProductText">
3226 <Item subindex="0" state="initial" error="0" value="Sample IO-Link Safety"/>
3227 </Variable>
3228 <Variable variableId="V_SerialNumber">
3230 </Variable>
3231 <Variable variableId="V_HardwareRevision">
3233 </Variable>
3234 <Variable variableId="V_FirmwareRevision">
3236 </Variable>
3237 <Variable variableId="V_ApplicationSpecificTag">
3238 <Item subindex="0" state="initial" error="0" value="IO-Link Safety"/>
3239 </Variable>
3240 <Variable variableId="V_ErrorCount">
3242 </Variable>
3243 <Variable variableId="V_DeviceStatus">
3245 </Variable>
3246 <Variable variableId="V_DetailedDeviceStatus">
3255 </Variable>
3256 <Variable variableId="V_ProcessDataInput">
3273 </Variable>
3274 <Variable variableId="V_NonSafetyParameter">
3276 </Variable>
3277 <Variable variableId="V_FST_DiscrepancyTime">
3279 </Variable>
3280 <Variable variableId="V_FST_Filter">
3282 </Variable>
3283 <Variable variableId="V_FSP_Authenticity">
3288 </Variable>
3289 <Variable variableId="V_FSP_Protocol">
3296 </Variable>
3297 <Variable variableId="V_FSP_ParamDescCRC">
3299 </Variable>
3300 </VariableInstanceData>
3301 </DeviceItem>
3302 </InvocationInterface>
3303 F.3.5 Temporary Backchannel File – TBF

3305 The TBF should be transfered by a new transaction of the communication server. This
3306 transaction is initiated by the Device Tool and can be performed automatically or upon user
3307 request. Transaction acknowledgements (TAF) should be implemented indicating reception of
3308 the instance values by the Master Tool or indicating a transaction fault (see F.3.6).
3309 F.3.5.2 Structure of the TBF

3310 The structure of the TBF is defined by the XML schema shown in F.9.4. This schema is built
3311 in a generic manner, which means, a new parameter does not require the schema itself to be
3312 updated. Thus, new parameters can be introduced without a new definition of the TBF
3313 structure.
3314 Namespace URI for this file is "http://www.io-link.com/DTI/2017/02/TBF".
3315 Figure F.8 shows the structure of the TBF.
1 ReturnInterfaceRequest 1 1 VariableInstanceData
1
DocumentInfo 1
version
1..*
Variable
variableId
1..*
Item
subindex
value
state
error
3316
3317 Figure F.8 – Structure of the TBF
3320 Table F.3 – Elements of the TBF
ReturnInterfaceRequest – – M 1.0 Root element

DocumentInfo version xsd:string M 1.0 Contains the schema version of the
TBF interface definition.
following regular expression:
\d+(\.\d+)*
One of the following values is
allowed:
"1.0" Used for TBF based on version
1.0 schema files
VariableInstanceData – – M 1.0 The element "VariableInstanceData"
is a container for "Variable" elements
(= parameter).
Variable variableId xsd:string M 1.0 Contains the parameter ID
Item subindex xsd:string M 1.0 See [1]
value xsd:string M 1.0 Contains the parameter value.
In absence of a parameter-specific
rule for the representation of the
value: Numerical values shall use the
decimal coding without left-hand
zeros. Negative values shall have a
hyphen (ASCII 45 dec) prefix.
Separator for floating point values is a
dot (ASCII 46 dec). Other separators
are not permitted.
state xsd:string M 1.0 Contains parameter status
error xsd:string M 1.0 Contains parameter error
3321
3322 F.3.5.3 Example of a TBF

3323 The following XML code shows the content of an exemplary TBF file.
3325 <ReturnInterfaceRequest xmlns="http://www.io-link.com/DTI/2017/02/TBF" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
3327 link.com/DTI/2017/02/TBF IOsafe_TBF_Schema_20170225.xsd">
3332 </Variable>
3335 </Variable>
3338 </Variable>
3341 </Variable>
3344 </Variable>
3350 </Variable>
3358 </Variable>
3361 </Variable>
3363 </ReturnInterfaceRequest>
3364
3365 F.3.6 Temporary Acknowledgment File – TAF

3367 Transaction acknowledgements should be implemented indicating reception of the instance
3368 values by the Master Tool or indicating a transaction fault. The same mechanism is used as
3369 with the TBF (see F.3.5).
3370 F.3.6.2 Structure of the TAF

3371 The structure of the TAF corresponds to the TBF structure in F.3.5.2. However, the root name
3372 has changed to "ReturnInterfaceResponse".
3373 F.3.6.3 Example of a TAF

3374 The following XML code shows the content of an exemplary TAF file.
3376 <ReturnInterfaceResponse xmlns="http://www.io-link.com/DTI/2017/02/TBF" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
3378 link.com/DTI/2017/02/TBF IOsafe_TBF_Schema_20170225.xsd">
3379 <Response value="true"/>
3380 </ReturnInterfaceResponse>
3381 F.3.7 Invocation behavior

3382 F.3.7.1 Conventions on Device Tool invocation
3383 Since the directory path of the TPF can contain "blank" characters, the Device Tool shall use
3384 the double quote character (") at the beginning and the end of the string when the ".exe" file is
3385 invoked.
3386 It is not required for the invoking Master Tool to monitor the status of the launched Device
3387 Tools. Even in case an instance of a Device Tool is already running, the Master Tool will
3388 generate a new Device Tool invocation whenever the user launches the same tool again.
3389 Therefore, it is the task of the Device Tool to handle multiple invocations. Table F.4 lists
3390 invocation cases and possible behaviors.
3391 Table F.4 – Invocation cases and behaviors
Case Behavior
Device Tool is launched once No conflicts

Device Tool is already running and – The Tool should be brought to the foreground of the GUI desktop
works on the same Device instance – Invocation of another instance of the Device Tool shall be avoided
as in a prior session.
Device Tool is already running and The behavior depends on the design of the Device Tool:
works on another Device instance – Another Tool instance is launched and opens its Device data
as provided by the DTI call. The
provided DeviceReference is known – The active GUI is brought to the foreground of the desktop in order to
in the Device Tool. show the Device data of the selected Device
Device Tool is already running and The behavior depends on the design of the Device Tool:
works on another Device instance – Another Tool instance is launched and creates a new Device instance
as provided by the DTI call. The
provided DeviceReference is not – The active GUI is brought to the foreground of the desktop in order to
known in the Device Tool. create a new Device instance of the selected Device
3392 If a Device Tool is invoked via DTI, this Tool should not call another Device Tool because the
3393 Communication Server cannot interconnect (no nested communication defined for a DTI
3394 Communication Server).
3395 F.3.7.2 Handling of the TPF

3396 The name of the TPF will be provided to the Device Tool as a command line parameter. This
3397 name shall consist of a drive letter, an absolute path expression and the file extension.
3398 Alternatively, the UNC notation can be used instead of the drive letter. The Master Tool is
3399 responsible to create the file and unlock it before the Device Tool is invoked in such a manner
3400 that the Device Tool has full access to the file. The file name itself is only temporary and a
3401 new file name is generated with each Tool invocation.
3402 After interpretation of the content of the TPF file, the Device Tool shall delete this file. Since
3403 the Master Tool can also delete this file when it is restarted, it is recommended for the Device
3404 Tool to make a "private" copy of the file when the Device Tool is launched.
3405 F.4 Device data objects (DDO)

3406 F.4.1 General
3407 There is no design goal for DTI, to harmonize the different object models of the Device Tools
3408 and the Master Tools as well as for engineering systems due to the tremendous variety and
3409 complexity. Instead of a common object model, the Device reference is the bridge between a
3410 DDO (e.g. parameter instance) in the Master Tool and a DDO in the Device Tool.
3411 F.4.2 Creating DDOs

3412 Since a Device Tool is invoked within the context of a Device in the Master Tool, the DDO
3413 shall be initially created in the Master Tool. This is performed via the IODD. For DTI, no
3414 extension in the description files is required. With the help of the system registry a Master
3415 Tool can find an appropriate Device Tool to handle the newly created DDO.
3416 Figure F.9 illustrates the activities during Device Tool invocation.
User Master_Tool Device_Tool
Device Tool launched
Menu: Create new Device Create new DDO

data object (DDO)
Optional: Update
Display: DDO [No Device Tool installed] DeviceCommReference
D1
[Device Tool installed]
Create DeviceReference Read selected

DeviceReference
Optional: Create [Known DeviceReference]

DeviceCommReference D2
[Unknown DeviceReference]
Display: DDO and menu
Get menu entries from PID [No unassigned DDOs]
items for Tool
D3
invocation
[Unassigned DDOs]
Invoke Tool Create TPF
Optional: Trigger GUI to
assign to existing DDO
Save changes
Launch Device Tool Optional: Trigger

wizard
Select one of the

available DDOs Create DDO
Store
DeviceReference
Optional: Store
DeviceCommReference
DDO is displayed Select DDO in GUI

in Device Tool
3417
3418 Figure F.9 – Activity diagram for the DDO handling
3419 The Master Tool shall generate a Device reference for each new instance of a Device, whose
3420 SDCI Device Identification is registered in the registry as described in Annex F.3.2. This
3421 reference shall be unique at least within the Master Tool project. It shall be used in the key-
3422 word “DeviceReference” of the TPF and shall not be changed for the lifetime of the Device.
3423 If the Master Tool supports Conformance Class 3 (see Annex F.8), it can additionally
3424 generate a Device communication reference for each new Device instance. This reference
3425 shall be unique within the PC. It shall be used in the keyword “DeviceCommReference” of the
3426 TPF and shall not be changed for the lifetime of the Device except when copying an entire
3427 Master Tool project or retrieving a Master Tool project. When the copying is done outside of
3428 the Master Tool (for example via the Windows Explorer), the Master Tool shall detect the copy
3429 when opening the project the next time and then issue new, unique Device communication
3430 references.
3431 It is the decision of the Master Tool whether the DDO reference is generated whenever a new
3432 instance is created or upon the first call of the Device Tool after the creation of the DDO.
3433 When a new instance of a DDO is created in the Master Tool, there is no corresponding DDO
3434 in the Device Tool at the first Tool invocation. In this case, the Device Tool shall create an
3435 own instance of the DDO in its own DDO administration. If the user must enter some more
3436 data, the Device Tool can start a wizard in order to guide the user. After this step, the
3437 reference shall be stored in the Device Tool project so that the Tool can select the right DDO
3438 when it is launched again with the same reference.
3439 If a DDO is created initially in the Device Tool, the corresponding DDO in the Master Tool
3440 cannot be created automatically. In this case, the user shall create a new DDO in the Master
3441 Tool manually. If the Device Tool is now launched in the context of the Master Tool, the
3442 Device Tool can show a list of unassigned DDOs of the same type and let the user decide
3443 which DDO of the Device Tool corresponds to the newly created DDO in the Master Tool.
3444 F.4.3 Copying DDOs

3445 When a DDO is copied in the Master Tool, only the IODD parameter settings are copied. For
3446 the new DDO instance, a new DDO reference (DeviceReference, DeviceCommReference)
3447 shall be generated by the Master Tool. The DDO is not copied in the Device Tool. At the next
3448 nvocation, a Device Tool can react on this new DDO reference. From the point of view of the
3449 Device Tool, there is no difference between a copied DDO and a newly created DDO.
3450 If a complete project is copied in the Master Tool, the DDO references shall not change. Only
3451 the DeviceCommReferences will be changed by the Master Tool to enable different routing
3452 info. The Master Tool shall copy all files in the "ProjectRelatedPath" directory to the new
3453 destination. If a Device Tool is launched from a copied project, it will find all Device Tool
3454 specific data as within the original project.
3455 F.4.4 Moving DDOs

3456 If a DDO is moved in the Master Tool to another location within the same project, the Device
3457 reference shall not change.
3458 In order to react in the Device Tool upon moved Devices besides the selected Device, the
3459 option "UsesMultipleDeviceInformation" shall be used.
3460 F.4.5 Deleting DDOs

3461 If a DDO is deleted in the Master Tool, the corresponding DDOs in the Device Tool should
3462 normally also be deleted. This cannot be done automatically due to a missing unique storage
3463 model (save, undo...) for all Tools (see Annex F.4.1).
3464 The Master Tool provides a list of used Device references in the TPF. This list can be
3465 interpreted by the Device Tool to find out, which DDOs of the same PLC in the Device Tool
3466 project are no more part of the TPF. If one or more DDOs are missing in the TPF, the Device
3467 Tool can now ask the user which DDOs to delete automatically or to keep internally as
3468 unassigned DDOs for a later reuse. Since this behavior of the Device Tool is optional, it shall
3469 be described in its PID file with feature name “SupportsObjectDeletion”.
3470 If a Device Tool does not implement this functionality, the Master Tool shall display a
3471 message informing the user that these changes shall be made manually in the Device Tool.
3472 F.5 Communication Interface

3473 F.5.1 General
3474 As already explained in Annex F.1, there is no seamless communication solution for stand-
3475 alone Device Tools such as "Dedicated Tools" for functional safety in IO-Link so far. The only
3476 possibility in the past has been a separate point-to-point communication connection, for
3477 example RS232, USB, or alike, between a Device and a PC running the Device Tool software.
3478 Each of these connections requires appropriate driver software with different programming
3479 API for the Device and for the different PC communication interfaces.
3480 This leads to the problem that a Device Tool either can work only with one particular
3481 communication interface or that the Device Tool has to implement different APIs for Device
3482 driver integration.
3483 Another problem in a plant is that the network structure often requires communication across
3484 network boundaries (Routing). Due to the many fieldbuses and different communication
3485 protocols, it is very cumbersome to achieve an integrated network with routing functions for
3486 Device Tools down to the associated Device (see Figure F.10).
3487 The second major part of DTI solves two problems:
3488 • All Devices/FS-Devices and their Device Tools/Dedicated Tools can rely on one particular
3489 communication interface.
3490 • The chosen communication technology is standardized in IEC 62453 and solves the
3491 routing problem across network boundaries.
FSCP: FS-Master
Engineering
description file
tool

FSCP-Host
FS-Master Tool
invocation
FSCP
FS-Master
tool
Proprietary
FS-Master
IO-Link communi-
cation (OD)
FS-
Device IODD IOPD
"Dedicated
Tool"
3492
3493 Figure F.10 – Communication routes between Device Tool and Device
3494 F.5.2 Principle of DTI communications

3495 The communication interface consists of a component which provides a unique interface (API)
3496 to the Device Tool. This component is able to provide communication functionality for different
3497 field busses and also proprietary network protocols. The communication parameters which are
3498 necessary to establish a connection are entered in the Master Tool and passed to the Device
3499 Tool when it is launched.
FS-Master Tool IODD

Engineering
System (FS-PCDT)
Dedicated Tool
Port Inter- Device Tool software (safety)
FDT, Configur- preter Interface (DTI)
TCI, or ation
others FS-Device
Tool
Backward
channel for
read/write IFdtCommunication
parameters (IO-Link)
Access to Tunneling
IO-Link to IO-Link
Master Device
CommServer
IO-Link
IFdtCommunication
or other solution
Communication
driver CommServer
Fieldbus
3500
3501 Figure F.11 – Routing across networks and IO-Link
3502 Figure F.10 shows fieldbus or proprietary networks between the PC and the Device. Figure
3503 F.11 shows the mapping to software and Communication Servers. In this case, the
3504 Communication Server (Fieldbus) requires information about the network protocol. This
3505 routing information is generated by the Engineering System and transferred to the
3506 Communication Server (Fieldbus). Due to the fact that manufacturer specific data has to be
3507 exchanged, the Communication Server and the Engineering System must be provided by the
3508 same manufacturer.
3509 The routing information for the second Communication Server (IO-Link) is generated by the
3510 Master Tool and transferred to this CS. When the Device Tool is started, only a
3511 communication reference to the Device is passed. This reference is forwarded from the
3512 Device Tool to the Communication Server. With the help of the routing information from the
3513 Engineering System, the Communication Server is able to create physical network addresses
3514 and to establish a connection to the Device. Figure F.12 shows the relationships between the
3515 components involved.
Master Tool DeviceCommReference, Device Tool

Communication Address
DeviceCommReference,
Communication Address
Routing info Communication

(DeviceCommReference) Server
3516
3517 Figure F.12 – Communication Server
3518 It is always possible for a Device Tool to use its native communication interfaces (for example
3519 serial RS232) as an alternative besides the Communication Server.
3520 F.5.3 Gateways

3521 A Communication Server allows a communication connection across network boundaries (see
3522 Figure F.11).
3523 The Engineering System, all Device Tools and the Communication Server are located on the
3524 same PC which is connected e.g. via an Ethernet adapter to a network. The target Devices
3525 can be found behind a gateway which can work in different ways. From the Device Tool point
3526 of view, it is irrelevant where the Device is located because the network structure is handled
3527 by the Communication Server.
3528 The Communication Server is potentially able to manage all gateway types which are
3529 supported by the Engineering System itself. The gateway functionalities itself are
3530 encapsulated by the Communication Server. Only gateway types known by the
3531 Communication Server can be supported (no nested communication).
3532 If a device can be reached through multiple paths in the network, it is up to the Engineering
3533 System to decide, which network path is used for communication.
3534 F.5.4 Configuration of the Communication Server

3535 In order to build the network communication addresses from the Device communication
3536 reference, the Communication Server requires configuration data from the Engineering
3537 System/Master Tool. The structure of configuration data itself and the way how the data is
3538 sent to the Communication Server is manufacturer specific and will not be standardized.
3539 F.5.5 Definition of the Communication Interface

3540 The Communication Server implements the interface "IFdtCommunication" and uses the
3541 "IFdtCommunication-Events" and "IFdtCommunicationEvents2" as described in IEC 62453. All
3542 other DTM interfaces which are described in IEC 62453 are not relevant for the Communi-
3543 cation Server. Due to this constraint, a Communication Server cannot be used in an FDT en-
3544 vironment as communication DTM.
3545 F.5.6 Sequence for establishing a communication relation

3546 An interaction of Engineering System/Master Tool, Device Tool and Communication Server
3547 (CS) is required to establish a communication relation.
3548 The sequence is as follows:
3549 At first, a Device is integrated into the Master Tool with the corresponding configuration file
3550 (IODD). Within the Engineering System, communication addresses and bus parameter are
3551 adjusted. Together with other network data, topology data for the network is the result.
3552 Furthermore, the Master Tool shall build a unique Device communication reference. This
3553 reference is passed to the Device Tool when it is launched with the help of the TPF (keyword
3554 “DeviceCommReference”). The Device Tool is now able to establish a connection to the
3555 Device using the Communication Server and Device communication reference.
3556 The Communication Server itself interprets the Device communication reference and converts
3557 it to network addresses. Therefore it uses the configuration data from the Master Tool.
3558 Because it is up to the CS to decide if the Device communication reference or the
3559 communication address itself is used, the Device Tool shall always pass both attributes in the
3560 ConnectRequest XML document.
3561 If no routing functionality is required, the CS does not require the proprietary configuration. In
3562 order to connect, the CS can use the communication address itself from the Master Tool.
3563 Figure F.13 shows how a communication connection is established.

Master Dev ice Com munic ation

Too l Too l Serv er
Exe _Call(DeviceCommRe ferenc e

, co mmServerProg ID,...)
Crea te(com mServ erProgI D)
Dev ice Too l create s new Get SupportedProt ocols()
Com munic ation S erver
insta nce Con nectRe quest()
Con nectRe sponse ()

Con nectRe quest c ontains
para meter Tran saction Reque st()
"De viceCom mRefe rence"
Tran saction Respo nse()
Disc onnect Request()
Disc onnect Respon se()
Destroy()
Dev ice Too l shall remove the

Com munic ation S erver
insta nce prior to it s exit
3564
3565 Figure F.13 – Sequence chart for establishing communication
3566 The passed ProgID (Keyword commServer-ProgID) can be used to create a new instance of
3567 the Communication Server by the Device Tool. There is a 1:1 relationship between Device
3568 Tool and Communication Server instance. The Communication Server instance is able to
3569 connect to one or more Devices.
3570 Figure F.14 shows a code fragment in C++ as an example on how to create a new instance.
commServer-ProgID of TPF
r1 = CLSIDFromProgID(L"TCI.MyCommunicationServer", &clsid);
r1 = CoCreateInstance (clsid, NULL, CLSCTX_INPROC_SERVER,
__uuidof (IFdtCommunication), (void**)&m_pITciCommunicationServer);
3571
3572 Figure F.14 – Create Communication Server instance
3573 It is recommended to create the Communication Server instance as "in process server"
3574 (CLSCTX_INPROC_SERVER) due to performance issues.
3575 After a new instance of the Communication Server is created, all methods of the interface
3576 "IFdtCommunication" can be called. At first a Device Tool shall call the
3577 "GetSupportedProtocols" method to find out if the required protocol is supported by the CS. If
3578 not, the Device Tool shall inform the user. A new connection is established with help of the
3579 function "ConnectRequest". Among others, as invocation parameter a pointer to the callback
3580 interface (Interface IFdtCommunicationEvents) is passed. This means that a Device Tool shall
3581 implement this interface.
3582 The Device Tool is responsible to release the Communication Server instance when the Tool
3583 exits. If the Communication Server instance was created in the process of the Device Tool, as
3584 recommended before, this is done automatically since the instance is terminated with the
3585 process of the Device Tool.
3586 F.5.7 Usage of the Communication Server in stand-alone mode

3587 If a Device Tool is not called from a Master Tool with DTI, it shall find out the ProgID of the
3588 Communication Server by itself. In this case the "Component Categories" of the system
3589 registry can be used (HKEY_CLASSES_ROOT\Component Categories).
3590 The following values are defined for the DTI Communication Server:
3591 Symbolic Name of CatID: CATID_DTI_CS
3592 UUID of CatID: {7DDC60A6-1FD4-45a2-917F-0F8FC371BC57}
3593 A Device Tool is able to find out the ProgID of the Communication Server with the help of the
3594 Standard Component Categories Manager. If more than one component is assigned to this
3595 category, the user of the Device Tool shall select one of the Communication Servers.
3596 If a Communication Server does not support the "Stand-Alone" mode (i.e. a Communication
3597 Server instance cannot be created by a Device Tool), a system registry entry should not be
3598 made.
3599 A Device Tool that supports Conformance Class 3 and is intended for "Stand-Alone" mode
3600 shall store the DeviceCommReferences together with its DDOs. Whenever the
3601 DeviceCommReference is changed by the Master Tool while copying the entire project or
3602 while retrieving the project, the Device Tool shall check and – if changed – update the
3603 DeviceCommReference when called from the Master Tool with DTI. There are two general
3604 possibilities:
3605 1) The Device Tool checks and updates the DeviceCommReference of a particular Device
3606 immediately before connection.
3607 NOTE After copy/retrieval of a Master Tool project, the user should call the Device Tool via DTI and connect to
3608 the particular Device(s) prior to the connection to this/these Device(s) later on in "Stand-Alone" mode.
3609 2) The Device Tool checks and updates the DeviceCommReferences of all Devices
3610 immediately after being called by the Master Tool via DTI.
3611 NOTE After copy/retrieval of a Master Tool project, the user should call the Device Tool via DTI. Then, all
3612 Devices can be connected later in “Stand-Alone” mode.
3613 F.5.8 IO-Link specifics

3614 The IO-Link schema defined in [16] shall be used as communication schema.
3615 Table F.5 shows the mapping between the TPF keywords and the attributes in the communi-
3616 cation schema.
3617 Table F.5 – Communication Schema mapping
Attribute of ConnectRequest element Parameter Keyword in TPF file Remarks

(FDTIOLinkCommunicationSchema.xml)
fdt:nodeId – Unused
systemTag "DeviceCommReference" attribute
of element "Device".
3618
3619 The communication parameters passed during the Device Tool invocation shall be used as
3620 input for the Connect Request XML document to be used in the connect method. Additionally,
3621 the device communication reference (Keyword "DeviceCommReference" in Table F.5) shall be
3622 entered in the Connect Request XML document as attribute “systemTag”. Figure F.15 shows
3623 an example.
<?xml version="1.0"?>
<FDT xmlns="x-schema:FDTIOLinkCommunicationSchema.xml"
xmlns:fdt="x-schema:FDTDataTypesSchema.xml">
<ConnectRequest systemTag="Controller3/Gateway2/Unit1"/>
</FDT>
DeviceCommReference of TPF
3624
3625 Figure F.15 – Example of a Connect Request XML document for IO-Link
3626 F.5.9 Changing communication settings

3627 If it is necessary to change the communication address (Master, port?) in the Master Tool, the
3628 Device Tool needs information about the new communication address. This shall be done via
3629 relaunching the Device Tool by the user of the Master Tool. During relaunch, the new
3630 communication parameters are passed to the Device Tool. With these communication para-
3631 meters a new communication relation can be established to the Device.
3632 If the Device communication reference is used instead of the communication address between
3633 Device Tool and Communication Server, no relaunch of the Tool is required, because the
3634 Device communication reference does not change whenever the communications address
3635 changes. In this case, the Communication Server itself can reconnect to the Device with the
3636 new communication address (Master, port).
3637 For an existing connection, changed communication parameters in the Master Tool project
3638 shall not have any impact. Changed communication parameters shall be used when a
3639 connection is (re)established.
3640 F.6 Reaction on incorrect Tool behavior

3641 Table F.6 describes the system reaction if a Master Tool or Device Tool works incorrectly.
3642 Table F.6 – Reaction on incorrect Tool behavior
Fault Description System reaction

XML structure of PID file The PID file of a Device Tool does The Master Tool should only show an error
not valid not validate with the XML Schema message if required schema elements or
in Annex F.9.1 attributes are missing. All unknown elements
or attributes shall be ignored.
XML structure of TPF file The TPF file generated by the The Device Tool should only show an error
not valid Master Tool does not validate with message if required schema elements or
the XML Schema in Annex F.9.3 attributes are missing. All unknown elements
or attributes shall be ignored.
Device Tool cannot be When the operation system is Master Tool shall show an error message (Tool
invoked instructed to create a new process cannot be invoked) with the name and path of
(Tool invocation) the function the exe file.
returns an error code.
Reason could be that the path of
the exe file in the system registry
is incorrect.
CommunicationServer The "CoCreateInstance" function The Device Tool should show an error
object cannot be created. returns an error code when an message.
See F.5.6 object with the ProgID of the TPF
should be instantiated.
TPF file not deleted by the The TPF file was not removed by Master Tool should delete the TPF file when it
Device Tool the Device Tool as described in is launched (garbage collection). If the file
Annex F.3.1 cannot be deleted, the Master Tool should not
show an error message.
DeviceCommReference not Device Tool is using a not existing The Device Tool should show an error
valid (Communication DeviceCommReference in the message.
channel cannot be estab- Master Tool.
lished). See Annex F.5.
3643
3644 F.7 Compatibility

3645 F.7.1 Schema validation
3646 XML documents can easily be validated with the help of standard parsers and schema files. If
3647 the structure of an XML document does not follow the rules defined in the corresponding
3648 schema, the XML parser rejects the document. This is not very practical if Tools with different
3649 versions of DTI files shall work together since a newer XML document cannot be processed
3650 by previous software.
3651 In order to implement a robust model, the Master Tool and the Device Tools shall ignore any
3652 XML attributes or elements not recognizable in a valid XML document. This means that XML
3653 schema validation shall not be used. The schema files in Annex F.9 are for information
3654 purposes only.
3655 The installation program of the Device Tool can always install the newest PID file version. The
3656 Master Tool shall ignore any unknown XML attributes or elements.
3657 F.7.2 Version policy

3658 If it is necessary to modify the structure definition of a TPF with the result that a new version
3659 of the invocation interface is defined, the Master Tool shall ensure that the right version of the
3660 TPF is created. That means it shall use an earlier version of the structure if the Device Tool is
3661 only able to support the earlier version.
3662 The PID file version of the Device Tool determines the newest supported version of the
3663 corresponding Device Tool. See Annex F.3.3 for details.
3664 If a Device Tool supports a newer version than the Master Tool, the Master Tool uses its
3665 newest TPF version. In this case the Device Tool shall work with the old schema version.
3666 F.8 Scalability

3667 F.8.1 Scalability of a Device Tool
3668 The manufacturer of a Device Tool can choose to support different function levels of DTI as
3669 shown in Table F.7.
3670 Table F.7 – DTI conformance classes
Conformance Class Description
C1 Setup program creates system registry entries as described in Annex F.3.2. This
(Navigation) allows the user to invoke the Device Tool from the context of a selected Device in the
Master Tool without any impact on an existing Device Tool itself.
C2 The Device Tool uses the information of the TPF. In this case, for example, the Tool
(Parameter transfer) is able to read FST parameter instances or to use a communication address for its
proprietary communication channel. This way, the user can be relieved from multiple
entries. The implementation effort is limited to evaluation of the TPF file for internal
initialization of the Device Tool.
C3 The full functionality is available if the Device Tool uses the DTI Communication
(DTI communication with Server. This component enables the Tool to manage all network boundaries
optional backchannel) implemented by the Master Tool. In this case the Device Tool shall support the
IFdtCommunication/IFdtCommunicationEvents/IFdtCommunicationEvents2 interface.
In case of the backchannel option, the Master Tool uses the information of the TBF.
In this case, for example, the Tool is able to read FST parameter instances or to use
the I/O Process Data description. This way, the user can be relieved from multiple
entries. The implementation effort is limited to evaluation of the TBF file for internal
processing of the Master Tool.
3671
3672 Table F.8 shows the DTI relevant features of a Device Tool.
3673 Table F.8 – DTI feature levels of Device Tools
Function Annex Conformance Class Feature Name for PID file
Make system registry entries F.3.2 C1 –

Provide PID file during F.3.3 C1 –
installation procedure
Avoid multiple program C2 –
instances
Interpret TPF F.3.4 C2 –
Delete TPF F.3.7.2 C2 –
Supports deletion of DDOs not F.4.5 C2 – optional feature SupportsObjectDeletion
Function Annex Conformance Class Feature Name for PID file

in TPF
Use the Communication C3 –
Server interface
3674
3675 F.8.2 Scalability of a Master Tool

3676 A Master Tool shall support all DTI feature levels/conformance classes.
3677
3678 F.8.3 Interactions at conformance class combinations

3679 Table F.9 defines how a Master Tool and a Device Tool shall interact depending on their
3680 conformance class.
3681 Table F.9 – Interactions at conformance class combinations
Master Tool Device Tool Interaction
C2 or C3 C1 Device Tool is launched, no parameters are passed.

The Master shall not generate a TPF because it would not be deleted by the
Device Tool.
C2 or C3 C2 Device Tool is launched, Parameters are passed through TPF.
C2 C3 Device Tool is launched, Parameters are passed through TPF.
C3 C3 Device Tool is launched, Parameters are passed through TPF.
Communication via Communication Server is possible.
3682
3683 F.9 Schema definitions

3684 F.9.1 General
3685 The schema definitions in this Annex F.9 are for information only (see Annex F.7.1).
3686 F.9.2 Schema of the PID

3687 Figure F.16 shows the XML schema of the Program Interface Description file.
3688
3689 Figure F.16 – XML schema of the PID file
3690 Figure F.16 is based on the XML code as follows:

3692 <xsd:schema xmlns="http://www.io-link.com/DTI/2017/02/PID" xmlns:prim="http://www.io-link.com/DTI/2017/02/Primitives"

3693 xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.io-link.com/DTI/2017/02/PID"
3694 elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">
3695 <xsd:import namespace="http://www.w3.org/XML/1998/namespace"/>
3696 <xsd:import namespace="http://www.io-link.com/DTI/2017/02/Primitives" schemaLocation="DTI-Primitives1.0.xsd"/>
3697 <xsd:element name="DocumentInfo">
3698 <xsd:complexType>
3699 <xsd:attribute name="version" use="required">
3700 <xsd:simpleType>
3701 <xsd:restriction base="xsd:string">
3702 <xsd:pattern value="V\d+(\.\d+){1,7}"/>
3703 </xsd:restriction>
3704 </xsd:simpleType>
3705 </xsd:attribute>
3706 </xsd:complexType>
3707 </xsd:element>
3708 <xsd:element name="ToolDescription">
3710 <xsd:attribute name="lang" type="xsd:string" use="required"/>
3711 <xsd:attribute name="name" type="xsd:string" use="required"/>
3712 <xsd:attribute name="description" type="xsd:string" use="required"/>
3714 </xsd:element>
3715 <xsd:element name="InvocationPrefix">
3717 <xsd:attribute name="name" use="required">
3719 <xsd:restriction base="xsd:string"/>
3723 </xsd:element>
3724 <xsd:element name="General">
3726 <xsd:sequence>
3727 <xsd:element ref="ToolDescription" maxOccurs="unbounded"/>
3728 <xsd:element ref="InvocationPrefix" minOccurs="0"/>
3729 </xsd:sequence>
3730 <xsd:attribute name="vendorName" type="xsd:string" use="required"/>
3732 </xsd:element>
3733 <xsd:element name="EntryPoints">
3735 <xsd:sequence>
3736 <xsd:element name="EntryPoint" maxOccurs="unbounded">
3738 <xsd:complexContent>
3739 <xsd:extension base="prim:ObjectT">
3740 <xsd:sequence>
3741 <xsd:element name="InfoText" maxOccurs="unbounded">
3743 <xsd:attribute name="lang" type="xsd:string" use="required"/>
3744 <xsd:attribute name="name" type="xsd:string" use="required"/>
3745 <xsd:attribute name="description" type="xsd:string" use="required"/>
3747 </xsd:element>
3749 <xsd:attribute name="id" type="prim:IdT" use="required"/>
3750 </xsd:extension>
3751 </xsd:complexContent>
3753 </xsd:element>
3756 </xsd:element>
3757 <xsd:element name="ConformanceClass">
3759 <xsd:attribute name="name" use="required">
3762 <xsd:enumeration value="C1"/>
3769 </xsd:element>
3770 <xsd:element name="ProgramInterface">
3772 <xsd:sequence>
3773 <xsd:element ref="DocumentInfo"/>
3774 <xsd:element ref="General"/>
3775 <xsd:element ref="EntryPoints"/>
3776 <xsd:element ref="ConformanceClass"/>
3779 </xsd:element>
3780 </xsd:schema>
3781
3782 F.9.3 Schema of the TPF

3783 Figure F.17 shows the XML schema of the Temporary Parameter File.
3784
3785 Figure F.17 – XML schema of the TPF

3788 <InvocationInterface xmlns="http://www.io-link.com/DTI/2017/02/TPF" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
3790 link.com/DTI/2017/02/TPF IOsafe_TPF_Schema_20170225.xsd">
3791 <General currentLanguage="en" commServerProgID="DTI.MyCommunicationServer"
3792 projectRelatedPath="\\ServerName\ShareName\Projects" masterId="444444" masterName="CPU-1" portId="0" portName="P1-
3793 4" schemaPath="d:\dti\schema" displayNameEs="MyMTName" busCategory="IOLink" selectedEntryPoint="1"
3794 conformanceClass="C3"/>
3795 <DeviceItem reference="Project1/Network2/Device3/1897212" commReference="Controller3/Gateway7/Unit4" vendorId="335"

3796 deviceId="6553616" productId="SafetyDeviceVariant" usedConfigFile="d:\IODDfiles\IO-Link-SafetyDevice-20170225-
3797 IODD1.1.xml" usedConfigFileCRC="1946410459">
3799 <Variable variableId="V_DirectParameters_1">
3816 </Variable>
3820 </Variable>
3821 <Variable variableId="V_VendorName">
3822 <Item subindex="0" state="initial" error="0" value="IO-Link Community"/>
3823 </Variable>
3824 <Variable variableId="V_VendorText">
3825 <Item subindex="0" state="initial" error="0" value="http://www.io-link.com"/>
3826 </Variable>
3827 <Variable variableId="V_ProductName">
3828 <Item subindex="0" state="initial" error="0" value="SafetyDevice"/>
3829 </Variable>
3830 <Variable variableId="V_ProductID">
3831 <Item subindex="0" state="initial" error="0" value="SafetyDeviceVariant"/>
3832 </Variable>
3833 <Variable variableId="V_ProductText">
3834 <Item subindex="0" state="initial" error="0" value="Sample IO-Link Safety"/>
3835 </Variable>
3836 <Variable variableId="V_SerialNumber">
3838 </Variable>
3839 <Variable variableId="V_HardwareRevision">
3841 </Variable>
3842 <Variable variableId="V_FirmwareRevision">
3844 </Variable>
3847 </Variable>
3848 <Variable variableId="V_ErrorCount">
3850 </Variable>
3851 <Variable variableId="V_DeviceStatus">
3853 </Variable>
3854 <Variable variableId="V_DetailedDeviceStatus">
3863 </Variable>
3864 <Variable variableId="V_ProcessDataInput">

3881 </Variable>
3884 </Variable>
3887 </Variable>
3890 </Variable>
3896 </Variable>
3904 </Variable>
3907 </Variable>
3909 </DeviceItem>
3910 </InvocationInterface>
3911
3912 F.9.4 Schema of the TBF

3913 Figure F.18 shows the XML schema of the Temporary Backchannel File.
3914
3915 Figure F.18 – XML schema of a TBF

3918 <xsd:schema xmlns="http://www.io-link.com/DTI/2017/02/TBF" xmlns:prim="http://www.io-link.com/DTI/2017/02/Primitives"
3919 xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.io-link.com/DTI/2017/02/TBF">
3920 <xsd:import namespace="http://www.io-link.com/DTI/2017/02/Primitives" schemaLocation="DTI-Primitives1.0.xsd"/>
3921 <xsd:element name="VariableInstanceData">
3923 <xsd:sequence>
3924 <xsd:element ref="Variable" maxOccurs="unbounded"/>
3927 </xsd:element>
3928 <xsd:element name="Variable">
3930 <xsd:sequence>
3931 <xsd:element ref="Item" maxOccurs="unbounded"/>
3933 <xsd:attribute name="variableId" type="xsd:string" use="required"/>
3935 </xsd:element>
3936 <xsd:element name="Item">
3938 <xsd:attribute name="value" type="xsd:string" use="required"/>
3939 <xsd:attribute name="subindex" use="required">
3941 <xsd:restriction base="xsd:unsignedShort">
3942 <xsd:maxInclusive value="255"/>
3946 <xsd:attribute name="state" use="required">
3949 <xsd:enumeration value="empty"/>
3950 <xsd:enumeration value="initial"/>
3951 <xsd:enumeration value="device"/>
3952 <xsd:enumeration value="read error"/>
3953 <xsd:enumeration value="write error"/>
3954 <xsd:enumeration value="valid"/>
3955 
3956 
3957 
3958 
3962 <xsd:attribute name="error" type="xsd:integer" use="required"/>
3964 </xsd:element>
3965 <xsd:element name="Response">
3967 <xsd:attribute name="value" type="xsd:boolean" use="required"/>
3969 </xsd:element>
3970 <xsd:element name="ReturnInterfaceRequest">
3972 <xsd:sequence>
3973 <xsd:element ref="VariableInstanceData"/>
3976 </xsd:element>
3977 <xsd:element name="ReturnInterfaceResponse">
3979 <xsd:sequence>
3980 <xsd:element ref="Response"/>
3983 </xsd:element>
3984 <xsd:group name="ReturnInterface">
3985 <xsd:choice>
3986 <xsd:element ref="ReturnInterfaceRequest"/>
3987 <xsd:element ref="ReturnInterfaceResponse"/>
3988 </xsd:choice>
3989 </xsd:group>
3990 </xsd:schema>
3991
3992 F.9.5 Schema of the TAF
3993 The schema of the TAF corresponds to the schema of the TBF in F.9.4.
3994 F.9.6 Schema of DTI primitives

3995 The DTI primitives are defined in the XML code as follows:
3997 <xsd:schema xmlns="http://www.io-link.com/DTI/2017/02/Primitives" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
3998 targetNamespace="http://www.io-link.com/DTI/2017/02/Primitives">
3999 <xsd:annotation>
4000 <xsd:documentation>In this schema, only the necessary types and attributes for DTI are used from the Common Primitives
4001 Schema.</xsd:documentation>
4002 <xsd:appinfo>
4003 <schemainfo versiondate="20170225"/>
4004 </xsd:appinfo>
4005 </xsd:annotation>
4006 
4007 <xsd:simpleType name="IdT">
4009 <xsd:documentation>Base Type for Object identifiers</xsd:documentation>
4011 <xsd:restriction base="xsd:string"/>
4013 <xsd:simpleType name="GuidT">
4015 <xsd:documentation>GUID</xsd:documentation>
4018 <xsd:pattern value="\{[0-9A-Fa-f]{8}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{12}\}"/>
4019 <xsd:pattern value="[0-9A-Fa-f]{8}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{4}\-[0-9A-Fa-f]{12}"/>
4022 
4023 
4024 
4025 <xsd:complexType name="DocumentT">
4027 <xsd:documentation>Type for all top level elements</xsd:documentation>
4029 <xsd:sequence>
4030 <xsd:element name="DocumentInfo" type="DocumentInfoT"/>
4033 <xsd:complexType name="DocumentInfoT">
4034 <xsd:attribute name="Version" type="xsd:string" use="required" fixed="1.1"/>
4036 
4037 
4038 
4039 <xsd:complexType name="ObjectT">
4041 <xsd:documentation>Base type</xsd:documentation>
4044 <xsd:complexType name="FeatureT">
4046 <xsd:documentation>Base type</xsd:documentation>
4048 <xsd:attribute name="Name" type="xsd:string" use="optional"/>
4050 <xsd:complexType name="ParameterT" mixed="true">
4051 <xsd:attribute name="Name" type="xsd:string" use="required"/>
4053 
4054 
4055 <xsd:complexType name="StringParameterT">
4056 <xsd:complexContent>
4057 <xsd:extension base="ParameterT">
4058 <xsd:attribute name="Value" type="xsd:string" use="required"/>
4059 </xsd:extension>
4060 </xsd:complexContent>
4062 
4063 <xsd:element name="Document" type="DocumentT">
4064 <xsd:unique name="OBJ-ID">
4065 <xsd:selector xpath=".//*"/>
4066 <xsd:field xpath="@ID"/>
4067 </xsd:unique>
4068 </xsd:element>
4069 <xsd:element name="Object" type="ObjectT"/>
4070 <xsd:element name="Parameter" type="ParameterT"/>
4071 <xsd:element name="StringParameter" type="StringParameterT" substitutionGroup="Parameter"/>
4072 <xsd:element name="Feature" type="FeatureT"/>
4073 <xsd:simpleType name="ConformanceClassEnumT">

4080 </xsd:schema>
4081
4082 Annex G
4083 (normative)
4084
4085 Main scenarios of IO-Link Safety
4086 Table G.1 shows main scenarios, the initial key parameters and the associated system
4087 activities. Its purpose is to provide a brief overview and it contains references to clauses with
4088 detailed descriptions.
4089 Table G.1 – Main scenarios of IO-Link Safety
Scenario Initial parameters System activities
OSSD operation Authenticity = 0 1. Modify FST parameter via "USB Master" (option; see
Port = 0 9.4.4.2);
FSP_TechParCRC ≠ 0 2. Adapt FSP_TechParCRC (see 11.7.8)
3. Plug, validate & play (default)
Commissioning Authenticity = 0 1. Set FSP_TechParCRC = 0 temporarily (FS-Device and
(Test = monitored Port = 0 FSP record)
operation) 2. Assign Authenticity and Port (FS-Device and FSP record)
FSP_TechParCRC ≠ 0
3. Assign protocol parameter and FST parameter
4. Run in test mode (Write FSP record: Authenticity +
FSP_TechParCRC not evaluated; other protocol
parameters adopted; Data Storage upload not required)
5. FS-Master Tool responsible to indicate test mode or to
prevent from running in test mode without Tool
connection.
Commissioning Authenticity = FSCP code 1. Assign actual FSP_TechParCRC (FS-Device and FSP
(Arm and validate) Port = port number record)
FSP_TechParCRC = 0 2. Upload parameters to Data Storage (FSP and FST), see
clause 9.4.5.4
3. Run in armed mode (Write FSP record: Authenticity +
FSP_TechParCRC compared but not adopted; other
protocol parameters adopted), see 11.7.6
4. Validate according to safety manual of FS-Device.
Replacement by Authenticity = 0 1. Download and adopt parameters from Data Storage (FSP
FS-Device with Port = 0 and FST) if Authenticity and Port = 0, see 9.4.6.1 and
factory settings w/o 9.4.6.2
tools FSP_TechParCRC ≠ 0
2. Run in armed mode (Write FSP record: Authenticity +
FSP_TechParCRC compared but not adopted; other
protocol parameters adopted), see 11.7.6
3. Validate according to safety manual of FS-Device.
Misconnection of Authenticity = FSCP code 1. No adoption of downloaded parameters from Data
configured FS- Port = port number Storage (FSP and FST) since Authenticity and Port ≠ 0
Devices 2. Run in armed mode (Write FSP record: Authenticity +
FSP_TechParCRC ≠ 0
FSP_TechParCRC compared; nothing adopted), see
11.7.6
3. Error message: "Misconnection" (0xB003 or 0xB004, see
Annex B)
4. Other protocol parameters not adopted.
4090
4091 "Local modification" of FST parameters as described in 9.4.5.4 and Table 13 is possible.
4092 However, the FSP_TechParCRC shall be assigned with the help of FS-Master Tool.
4093 Annex H
4094 (normative)
4095
4096 System requirements
4097 H.1 Indicators
4098 H.1.1 General
4099 Indicators for FS-Devices are not mandatory since for example proximity sensors may be too
4100 small for LEDs (light emitting diode).
4101 FS-Masters and FS-Devices may be used in a mix of different technologies such as
4102 • Fieldbus safety modules for inputs (e.g. F-DI module) or outputs (e.g. F-DO module);
4103 • Safety devices such as light curtains connected to fieldbuses via FSCPs;
4104 • IO-Link Masters and Devices.
4105 Thus, it is the designer's responsibility to layout the indication of the signal status, modes, or
4106 operations for FS-Masters and FS-Devices.
4107 H.1.2 OSSDe

4108 In case an FS-Master port is running in OSSDe mode it behaves similar to an F-DI module
4109 port. One possibility of indication is using the same indication as with the SIO mode.
4110 H.1.3 Safety communication

4111 In case an FS-Master port is running in SCL mode, the normal non-safety operation indication
4112 can be used also.
4113 H.1.4 Acknowledgment request

4114 A machine is not allowed to restart automatically after a stop. Usually, after repair or
4115 clearance, the signal/service "ChFAckReq" is switched ON as specified in 11.10.4 and
4116 11.10.5. It is highly recommended to indicate this signal on an FS-Master port and optionally
4117 on FS-Devices where it is likely to cause a trip due to high frequency or duration of exposure
4118 to a safety function.
4119 H.2 Installation guidelines, electrical safety, and security

4120 IO-Link installation guidelines shall be considered (see [21]).
4121 Only FS-Masters and FS-Devices providing a short form functional safety assessment report
4122 according to IEC 61508 or ISO 13849-1 together with a certificate of the assessment body are
4123 permitted. The short form report shall indicate all considered clauses and paragraphs of the
4124 used relevant standards and the corresponding assessment results.
4125 Wireless connection between FS-Master and FS-Device is only permitted if interdependency
4126 with other wireless connections can be precluded, for example via inductive couplers.
4127 No components in the link between FS-Master and FS-Device are permitted that are storing,
4128 inserting, or delaying messages.
4129 Manufacturer/vendor of FS-Masters and/or FS-Devices shall define installation constraints for
4130 the operation of OSSD devices or FS-Devices in OSSDe mode within their safety manuals.
4131 Requirements of IEC 61010-2-201 (see [4]) and IEC 60204-1 with respect to electrical safety
4132 (SELV/PELV) shall be observed.
4133 The zones and conduit concept of IEC 62443 applies for security and/or the rules of the
4134 applicable FSCP system.
4135 H.3 Safety function response time

4136 Safety manuals of FS-Master shall provide information on how to determine the safety
4137 function response time for OSSDe and for communication modes.
4138 H.4 Duration of demands

4139 Short demands of FS-Devices may not trip a safety function due to its chain of independent
4140 communication cycles across the network. Therefore, a demand shall last for at least two SCL
4141 (SPDU) cycles.
4142 H.5 Maintenance and repair

4143 FS-Devices can be replaced at runtime. Restart of the corresponding safety function is only
4144 permitted if there is no hazardous process state and after an operator acknowledgment.
4145 H.6 Safety manual

4146 FS-Masters and FS-Devices shall provide safety manuals according to the relevant national
4147 and international standards, for example IEC 61784-3-0, Edition 3.
4148 Manufacturer/vendor of FS-Masters and/or FS-Devices shall specify appropriate mitigation

4149 means in the safety manual for the deployment of IO-Link Safety components in harsh
4150 industrial environment such as in EMC zones B and C according to IEC 61131-2.
4151 Manufacturer/vendor of FS-Masters and/or FS-Devices shall define all constraints for the
4152 operation of OSSD devices or FS-Devices in OSSDe mode within their safety manuals.
4153 Manufacturer/vendor of FS-Masters and/or FS-Devices shall define all constraints for the
4154 operation of FS-Devices in communication mode within their safety manuals such as
4155 limitations with respect to storing elements, inductive or optical couplers, and alike.
4156 Manufacturer/vendor of FS-Masters and/or FS-Devices shall define the maintenance rules
4157 with respect to the PFH-Monitor (see Table 30).
4158 Annex I
4159 (normative)
4160
4161 Assessment
4162 I.1 General
4163 Functional safety assessments can only be performed if hardware and software are provided.
4164 Thus, the actual assessment of IO-Link Safety can only comprise a concept approval as a
4165 precondition for the conformity of implementations. This can result in precertified development
4166 kits to save time and effort.
4167 I.2 Safety policy

4168 In order to prevent and protect the manufacturers and vendors of FS-Masters and FS-Devices
4169 from possibly misleading understandings or wrong expectations and gross negligence actions
4170 regarding safety-related developments and applications the following shall be observed and
4171 explained in each training, seminar, workshop and consultancy.
4172 • Any non-safety-related device automatically will not be applicable for safety-related
4173 applications just by using fieldbus or IO-Link communication and a safety communication
4174 layer.
4175 • In order to enable a product for safety-related applications, appropriate development
4176 processes according to safety standards shall be observed (see IEC 61508, IEC 60204-1,
4177 IEC 62061, ISO 13849) and/or an assessment from a competent assessment body shall
4178 be achieved.
4179 • The manufacturer of a safety product is responsible for the correct implementation of the
4180 safety communication layer technology, the correctness and completeness of the product
4181 documentation and information.
4182 • Additional important information about current corrigendums through concluded change
4183 requests shall be considered for implementation and assessment. This information can be
4184 obtained from the IO-Link Community.
4185 I.3 Obligations

4186 As a rule, the international safety standards are accepted (ratified) globally. However, since
4187 safety technology in automation is relevant to occupational safety and the concomitant
4188 insurance risks in a country, recognition of the rules pointed out here is still a sovereign right.
4189 The national "Authorities" decide on the recognition of assessment reports.
4190 I.4 Concept approval

4191 For the approval of the safety concepts of IO-Link Safety the following has been provided by
4192 the community:
4193 • This document (specification of IO-Link Safety)

4194 • Documentation of the modelling, the model checking, and the simulation including fault
4195 injection of the IO-Link safety communication layer (SCL)
4196 • Document "Safety considerations" with Functional Safety Management, calculation of
4197 relevant Residual Error Rates, and software tool chain FMEA
4198 • Document "Document Management and Working Group rules"
4199
4200 Annex J
4201 (normative)
4202
4203 Details of "Classic" port class B
4204
4205 J.1 "Classic" power supply option

4206 The IO-Link connection system provides dedicated power lines in addition to the signal line as
4207 shown in Figure J.1. The communication section of a Device/FS-Device shall always be
4208 powered by the Master/FS-Master using the power lines defined in the 3-wire connection
4209 system (Power1) in [1]. Its maximum supply current is defined in 5.9 and Table 7.
4210 The technology/application part of a Device/FS-Device can be powered by one of three ways:
4211 • via the power lines of the 3-wire connection system (class A ports), using Power1;
4212 • via the extra power lines of the 5-wire connection system (class B ports), using an extra
4213 power supply (Power2) at the Master/FS-Master;
4214 • via a power supply at the Device/FS-Device (design specific) that shall be nonreactive to
4215 Power 1.
Isolated from Power1
Port Class B (M12)
2 Protection
1 P24 (Act) Power2

extra
PIN 2: P24 (extra power supply for
4 Power1 power
power Devices, current is
C/Q power supply
manufacturer dependent)
3 supply
PIN 5: N24
PIN 4: DI; COMx; DO
5
N24 (Act)
4216
4217 Figure J.1 – "Classic" port Class B definitions
4218 Figure J.1 shows also an extra power supply (Power2) intended for Devices/FS-Devices
4219 requiring more supply current for their individual technology/application such as actuators.
4220 Class B ports shall be marked to distinguish from Class A ports due to risks deriving from
4221 incompatibilities on pin 2 and pin 5.
4222 The maximum current available from this extra power supply is specified in Table J.1.
4223 Table J.1 – Electric characteristic of Power2
VPN24 M Extra DC supply 20 a) 24 30 V

voltage for Devices
IPN24 M Extra DC supply 1,6 b) n/a 3,5 c) A
current for Devices
a) A minimum voltage shall be guaranteed for testing at maximum recommended supply current. At the FS-
Device side 18 V shall be available in this case.
b) Minimum current in order to guarantee a high degree of interoperability.
c) The recommended maximum current for a wire gauge of 0,34 mm 2 and standard M12 connector is 3,5 A.
Maximum current depends on the type of connector, the wire gauge, maximum temperature, and simultaneity
factor of the ports (check user manual of a Master).
4224
4225 J.2 Rules

4226 As a general rule for non-safety Devices it is recommended not to consume more than the
4227 minimum current a Master shall support (see Table 6 in [1]) in order to achieve easiest
4228 handling ("plug & play") of IO-Link Master/Device systems without inquiries, checking, and
4229 calculations.
4230 Whenever the Device requires more than the minimum current the capabilities of the
4231 respective Master port and of the cabling shall be checked.
4232 FS-Devices should follow this recommendation also. However, 5.9 and Table 7 show mitiga-
4233 tion means for FS-Devices and FS-Masters to certain extend.
4234 In general, the requirements of Devices/FS-Devices shall be checked whether they meet the
4235 available capabilities of the Master/FS-Master. The simultaneity factor for the Master/FS-
4236 Master ports shall be observed.
4237 Power2 on port class B shall meet the following requirements
4238 • electrical isolation of Power2 from Power1;

4239 • degree of isolation according to IEC 60664 (clearance and creepage distances);
4240 • electrical safety (SELV) according to IEC 61010-2-201:2017;
4241 • direct current with P24 (+) and M24 (-);
4242 • EMC tests shall be performed with maximum ripple and load switching
4243 • Device shall continue communicating correctly even in case of failing Power2
4244
4245 Figure J.2 shows a possible layout of a cable for port Class B operation.
4246
4247 Figure J.2 – Possible layout of cable with Power1 and Power2
4248 In case of functional safety, the following standards shall be observed whenever applicable:
4249 • ISO 13849-2:2012

4250 • IEC 60204-1
4251 • VDE 0298, Part 4:2013 (Current ratings for flexible cables)
4252 • VDE 0891-1:1990 (Use of cables and insulated wires for telecommunication systems and
4253 information processing systems; general directions)
4254 Annex K
4255 (normative)
4256
4257 Test of FS-Master and FS-Device
4258 This part will be provided at a later date.
4259
4260 Bibliography
4261 [1] IO-Link Community, IO-Link Interface and System, V1.1.2, July 2013, Order No.
4262 10.002
4263 [2] IEC 61131-9, Programmable controllers – Part 9: Single-drop digital communication
4264 interface for small sensors and actuators (SDCI)
4265 [3] IEC 61784-3 Ed 3.0: Industrial communication networks – Profiles – Part 3: Functional
4266 safety fieldbuses – General rules and profile definitions
4267 [4] IEC 61010-2-201:2017, Safety requirements for electrical equipment for measurement,
4268 control and laboratory use – Part 2-201: Particular requirements for control equipment
4269 [5] ISO/IEC 19505-2:2012, Information technology – Object Management Group Unified
4270 Modeling Language (OMG UML) – Part 2: Superstructure
rd
4271 [6] Bruce P. Douglass, Real Time UML – Advances in the UML for Real-Time Systems, 3
4272 Edition, Addison-Wesley, ISBN 0-321-16076-2
4273 [7] Chris Rupp, Stefan Queins, Barbara Zengler, UML 2 glasklar – Praxiswissen für die
4274 UML-Modellierung. Hanser-Verlag, 2007, ISBN 978-3-446-41118-0
4275 [8] IEC/TR 62390, Common Automation Device – Profile Guideline
4276 [9] IO-Link Community, IO Device Description (IODD), V1.1, July 2011, Order No. 10.012
4277 [10] IO-Link Community, IO-Link Test, V1.1.2, July 2014, Order No. 10.032
4278 [11] IO-Link Community, IO-Link Safety (Single Platform) – Requirements, Use Cases, and
4279 Concept Baseline, V1.0, November 2014, Order No. 10.062
4280 [12] Position Paper CB24I, Classification of Binary 24V Interfaces – Functional Safety
4281 aspects covered by dynamic testing, Edition 2.0.1:
4282 https://www.zvei.org/verband/fachverbaende/fachverband-automation/schaltgeraete-
4283 schaltanlagen-industriesteuerungen/
4284 [13] IO-Link Community, IO-Link Profile BLOB & FW-Update, V1.0, June 2016, Order No.
4285 10.082
4286 [14] Klaus Grimmer, AIDA_IP-67-Safety_Positionspapier, June 27th, 2013
4287 [15] FDT Joint Interest Group, FDT 2.0 – Specification, V1.0, Order No. 0001-0008-000
4288 [16] FDT Joint Interest Group, FDT for IO-Link – Annex to FDT Specification – Based on
4289 FDT Specification Version 1.2.1, V1.0, Order No. 0002-0013-000
4290 [17] IEC 62453 series: Field device tool (FDT) interface specification
4291 [18] CRC signature calculator for a seed value of "0":

4292 https://www.ghsi.de/CRC/index.php?Polynom=10100111010101011&Message=1%0D
4293 %0A (Date: 29-Jan-2017)
4294 [19] Philip Koopman, Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded
4295 Networks, The International Conference on Dependable Systems and Networks, DSN-
4296 2004.
4297 [20] Philip Koopman, Best CRC Polynomials, https://users.ece.cmu.edu/~koopman/crc/

4298 (Date: 29-Jan-2017)
4299 [21] IO-Link Community, IO-Link Design Guideline, V1.0, November 2016, Order No.
4300 10.912
4301 ________
 Copyright by:
IO-Link Community
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/

IO-Link Safety System-Extensions 10092 V10 Apr17

Uploaded by

Copyright:

Available Formats

IO-Link Safety System-Extensions 10092 V10 Apr17

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IO-Link Safety System-Extensions 10092 V10 Apr17

Uploaded by

Copyright:

Available Formats

IO-Link Safety

Order No: 10.092

File name: IO-Link_Safety_System-Extensions_10092_V10_Apr17.doc

© Copyright IO-Link Community 2017 - All Rights Reserved Page 2 of 160

5.10 Medium ................................................................................................................. 41

11.5.2 SCL state machine of the FS-Master ............................................................. 64

Annex B (normative, non-safety related) Extensions to EventCodes .................................... 95

F.3.5 Temporary Backchannel File – TBF ............................................................. 131

I.3 Obligations ......................................................................................................... 155

Figure 1 – Relationship of this document to standards .......................................................... 12

Figure 37 – Positioning of the IO-Link Safety Communication Layer (SCL) ........................... 56

Figure F.3 – Example of a DTI registry ................................................................................ 121

Table 25 – Order of values and qualifier ............................................................................... 63

Design of safety-related electrical, electronic and program-

SIL based PL based

IEC 61000-1-2 IEC 60204-1

Key (yellow) safety-related standards/documents (blue) fieldbus-related standards

20 Figure 1 – Relationship of this document to standards

21 The main advantages of the IO-Link technology are:

43 The structure of this document is described in 4.9.

47 0.2 Patent declaration

RIO FS-DI IOL-S RIO FS-DI IOL-S

 Local signal processing

 Same FS-Device (OSSDe)

 Combi on Port Class B

80 Figure 2 – IO-Link Safety on single platform

118 IEC 61508-2:2010, Functional safety of electrical/electronic/programmable electronic safety-

121 IEC 61508-3:2010, Functional safety of electrical/electronic/programmable electronic safety-

128 IEC 62453, Field device tool (FDT) interface specification

135 3 Terms, definitions, symbols, abbreviated terms and conventions

305 3.2 IO-Link Safety: Additional terms and definitions

314 SOURCE: [IEC 61508-4:2010], [IEC 61158]

322 SOURCE: [IEC 61508-4:2010, modified], [ISO/IEC 2382-14.01.11, modified]

330 SOURCE: [IEC 61508-4:2010, modified], [ISO/IEC 2382-14.01.10, modified]

350 [SOURCE: IEC 61784-3:2015 modified]

352 3.3 Symbols and abbreviated terms

OK "OK", values or state correct

364 3.4.2 Memory and transmission octet order

"Big endian" Depending on the architecture

n+1 LSO MSO n+1 Memory

Transmission MSO LSO

371 Figure 3 – Memory and transmission octet order

372 4 Overview of IO-Link Safety

To upper level safety system

FS-Device Application FS-Master Application

IO-Link + IO-Link Safety data transmission

382 Figure 4 – IO-Link Safety communication layer model

395 IO-Link Safety does not support

398 4.1.2 From "analog" and "switching" to communication

IOL-OSSD Pin Signal Definition Standard

IOL-OSSD 3 L- 0V IEC 61131-2

Key: IOL-OSSDe = Equivalent switching redundant signals

407 Figure 5 – Port interface extensions for IO-Link Safety

FS-AI FS-DI FS-DO FS-Master

e.g. 0 …10 V OSSD PM IO-Link Safety

Measurement: Electro-mechanics: Electro-mechanics: Measurement: Sensors: Actuators:

414 Figure 6 – Migration to IO-Link Safety

420 4.1.3 Minimized paradigm shift from FS-DI to FS-Master

423 setup an authenticity code switch or adequate software solution;