SIC RTUs Safety ENG PDF

Preface, Table of Contents
Principles of Functional Safety 1

SICAM RTUs
SAFETY Functional Safety with SICAM RTUs 2
Safety System Description 3
Safety-Manual
Safety System Configuration 4
Functional Safety according to: Workflows for working with SICAM Safety 5
− IEC 61508
− IEC 61511 (ed.1) Operating Modes 6
− IEC 62061
−
−
EN ISO 13849
EN 50126 [2]
Error Detection and Management 7
−
−
EN 50128 [4]
EN 50129 [3]
System Response Time 8
− EN 50159-1 [5]
Safety Parameter 9
Technical Data 10
Guidelines for Programming 11
Checklists A
Installation Declaration B
TÜV Certificate C
Literature, Glossary
DC0-117-2.04
Note
Please observe Notes and Warnings for your own safety in the Preface.
This document is a translation of the original document

Disclaimer of Liability Copyright
Although we have carefully checked the contents of this publication Copyright © Siemens AG 2015
for conformity with the hardware and software described, we cannot The reproduction, transmission or use of this document or its
guarantee complete conformity since errors cannot be excluded. contents is not permitted without express written authority.
The information provided in this manual is checked at regular Offenders will be liable for damages. All rights, including rights
intervals and any corrections that might become necessary are created by patent grant or registration of a utility model or design,
included in the next releases. Any suggestions for improvement are are reserved.
welcome.
Subject to change without prior notice.
Document Label:
SICRTUs-HBSAFETY-ENG_V2.04
Issuing date
2015.03.13
Siemens AG Order No.: DC0-117-2.04

Energy Automation
Humboldtstraße 59
90459 Nürnberg
Deutschland
Preface
Purpose of this manual
This manual describes the safety-oriented use of SICAM RTUs. It explains the measures
necessary in order to plan and implement a safety-relevant process.
Take these measures into consideration for all projects in which safety components of
SICAM RTUs are used.
Scope of Validity
· SICAM AK 3
─ CPCX26 ....................... (Rev. 01 and higher)
─ PCCX26 ....................... (Rev. 01 and higher)
─ SPLC01........................ (Rev. 02 and higher))
─ CP-2019 ....................... 6MF10132CA100AA0 (ab BC2-019--.03)
· SICAM AK
─ PCCX25 ....................... (Rev. 08 and higher)
─ SPLC01........................ (Rev. 01 and higher)
─ CP-2017 ....................... 6MF10130CA170AA0 (from BC2-017--.14)
· SICAM TM
─ SPLC01........................ (Rev. 02 and higher)
─ CP-6014 ....................... 6MF11130GA140AA0 (ab GC6-014--.14)
─ USIO66 ........................ (Rev. 05 and higher)
─ DI-6170 ........................ 6MF11130GB700AA0 (from GC6-170--.03)
─ DO-6270....................... 6MF11130GC700AA0 (from GC6-270--.03)
─ AI-6370 ........................ 6MF11130GD700AA0 (from GC6-370--.03)
· SICAM TOOLBOX II .......... (V5.10 Hotfix 02 and higher)

─ Safety V&V ................... (V1.0 and higher)
─ Safety Monitor .............. (V1.0 and higher)
─ CAEx safety Toolchain .. (V1.0 and higher)
Target Group
This manual is intended for persons who are entrusted with the planning, parameterization,
commissioning and maintenance of safety-oriented SICAM RTUs.
Conventions Used
· Manuals that are referenced are written in italics

e.g. Common Functions, System and Basic System Elements, section Information
Objects.
· Menu paths, operator inputs, commands are written in bold letters.
e.g.: Authorizations → User/Role Administration → Define User ...
· SICAM TOOLBOX II parameters are shown with the font Courier in violet.
e.g.: Additional parameters | Remote operation
SICAM RTUs, SAFETY 3

DC0-117-2.04, Edition 04.2015
Placement into the Information Landscape
For the work with SICAM RTUs, depending on the case of application you require the
following specified documentation.
Document name Item number

SICAM AK 3 System Description MC2-024-2
SICAM AK 3 User Manual DC2-027-2
SICAM AK System Description MC2-021-2

SICAM AK User Manual DC2-017-2
SICAM TM CP-6014/CPCX65 System Element Datasheet MC6-033-2

SICAM TM Operation and Maintenance DC6-017-2
SICAM TM Installation DC6-015-2
SICAM TM 1703 I/O-Modules DC6-041-2
Common Functions Peripheral Elementes according to IEC 60870-5-101/104 DC0-011-2

SICAM 1703 Common Functions System and Basic System Elements DC0-015-2
SICAM RTUs • Ax 1703 Common Functions Protocol Elements DC0-023-2
SICAM RTUs Platforms – Configuration - Automation Units and Automation DC0-021-2
Networks
SICAM TOOLBOX II Online-Help

CAEx plus Online-Help
CAEx safety Online-Help
Further Support
For more information, please contact our Customer Support Center:

Phone: +49 (0)180 524 70 00
Fax: +49 (0)180 524 24 71
(charges depending on provider)
e-mail: support.ic@siemens.com
The Siemens Power Academy offers a comprehensive program of professional training events
in the fields of power generation, distribution and transmission.
Main training centers are:
Nuremberg, Germany (Head Office) Vienna, Austria

Phone: +49 911 433 7415 Phone: +43 51707 31143
Fax: +49 911 433 5482 Fax: +43 51707 55243
power-academy.ptd@siemens.com power-academy.at@siemens.com
Schenectady, NY, USA Hebburn, United Kingdom

Phone: +1 518 395 5005 Phone: +44 1914 953449
Fax: +1 518 346 2777 Fax: +44 1914 953693
pti-edpro.ptd@siemens.com pti-training.stdl.uk@siemens.com
4 SICAM RTUs, SAFETY

DC0-117-2.04, Edition 04.2015
Notes on Safety
This manual does not constitute a complete catalog of all safety measures required for
operating the equipment (module, device) in question because special operating conditions
might require additional measures. However, it does contain notes that must be adhered to for
your own personal safety and to avoid damage to property. These notes are highlighted with a
warning triangle and different keywords indicating different degrees of danger.
Danger
means that death, serious bodily injury or considerable property damage will occur, if the appropriate
precautionary measures are not carried out.
Warning
means that death, serious bodily injury or considerable property damage can occur, if the appropriate
precautionary measures are not carried out.
Caution
means that minor bodily injury or property damage could occur, if the appropriate precautionary measures
are not carried out.
Note
is important information about the product, the handling of the product or the respective part of the
documentation, to which special attention is to be given.
Qualified Personnel
Properly trained personnel are persons with all the following characteristics:
· persons planning, developing, assembling and/or commissioning safety-related E/E/PE

systems, subsystems or elements
· persons that given their experiences and/or training are authorized to perform the above
mentioned activities and are able to detect and prevent possible risks
In particular, persons using CAEx safety V&V Offline must not have a deficiency in their
color vision (such as a red-green color blindness).
· persons with knowledge of relevant safety concepts for automation engineering
· persons familiar with the underlying standards and regulations (see under section
Literature for the underlying standards)
· persons familiar with the instructions of this document
Sufficient language skills are required in order to understand all instructions given in this
document.
Warning
The use, the setting into operation and the operation of one of the items of operating equipment described
in this manual (module, device, configuration tool) may only be carried out by qualified personnel.
Use as Prescribed
The equipment (device, module) must not be used for any other purposes than those
described in the Catalog and the Technical Description. If it is used together with third-party
devices and components, these must be recommended or approved by Siemens.
Correct and safe operation of the product requires adequate transportation, storage,
installation, and mounting as well as appropriate use and maintenance.

DC0-117-2.04, Edition 04.2015
During operation of electrical equipment, it is unavoidable that certain parts of this equipment
will carry dangerous voltages. Severe injury or damage to property can occur if the
appropriate measures are not taken:
· Before making any connections at all, ground the equipment at the PE terminal.
· Hazardous voltages can be present on all switching components connected to the power
supply.
· Even after the supply voltage has been disconnected, hazardous voltages can still be
present in the equipment (capacitor storage).
· Equipment with current transformer circuits must not be operated while open.
· The limit values indicated in the manual or the operating instructions must not be
exceeded; that also applies to testing and commissioning.
Consider obligatory the safety rules for the accomplishment of works at electrical plants:
1. Switch off electricity all-pole and on all sides!

2. Ensure that electricity cannot be switched on again!
3. Double check that no electrical current is flowing!
4. Discharge, ground, short circuit!
5. Cover or otherwise isolate components that are still electrically active!
CAEx safety is used in the defined development process by properly trained personnel in
order to commission and operate applications only on SICAM RTUs, up to max. SIL 2,
according "IEC 61508 (2010)".
This document is only valid for SICAM safety, even if the term "E/E/PE system” is used.
Requirements for the development process
A defined development process is required for the development and the commissioning of an
application.
The development process must deal with the requirements of the appropriate underlying
standard, in particular the required validation and verification measures must be dealt with.
The workflows presented in this manual (see section Workflow for working with SICAM
Safety.) illustrate the usage of CAEx safety. They are no substitutes for a development
process and they do not claim to be exhaustive regarding the requirements of the underlying
standards.

DC0-117-2.04, Edition 04.2015
Table of Contents
1 Principles of Functional Safety .................................................................................. 13
1.1 Introduction .................................................................................................... 14

1.2 Legal Basis..................................................................................................... 15
1.3 Machinery Directive ........................................................................................ 16
1.4 Standards for Construction and Risk Assessment ........................................... 17
1.5 Standards for Safety-related Controllers ......................................................... 18
1.6 IEC 61508 – Basic Standard........................................................................... 19
1.7 IEC 62061 ...................................................................................................... 20
1.8 EN ISO 13849 ................................................................................................ 21
1.9 EN 5012x ....................................................................................................... 22
2 Functional Safety with SICAM RTUs .......................................................................... 23
2.1 Introduction .................................................................................................... 24

2.2 Achievable Safety Classes ............................................................................. 25
2.2.1 Overall System .......................................................................................... 25
2.2.2 Modules .................................................................................................... 25
2.3 Safety Components of SICAM RTUs .............................................................. 26
2.3.1 System Overview....................................................................................... 26
2.3.2 Safety Components ................................................................................... 27
2.4 Proper Intended Use ...................................................................................... 28
2.5 General Safety Assessment ........................................................................... 29
2.5.1 Safety Assessment of SICAM RTUs .......................................................... 29
2.5.2 Types of Error, Error Detection and Error Reaction in SICAM RTUs........... 30
2.5.3 Data Saving and Data Security in SICAM RTUs......................................... 30
2.5.3.1 Data Saving.......................................................................................... 30
2.5.3.2 Data Security........................................................................................ 31
3 Safety System Description ......................................................................................... 33
3.1 Concept.......................................................................................................... 34
3.2 Safety Functions............................................................................................. 38
3.2.1 Periodical Safety Functions ....................................................................... 38
3.2.2 Integrated Error Monitoring in the Safety Firmware (SPLC01) .................... 38
3.2.3 Integrated Error Monitoring in the Safety I/O Module .................................. 38
3.2.4 Secure Communication between SICAM Safety PLC’s .............................. 38
3.3 Segregation of Safe and Standard Firmware................................................... 39
3.4 Recognizability of Safety Product Components ............................................... 40
3.5 System Limits ................................................................................................. 41
3.6 Safety Firmware AP-0771/SPLC01 ................................................................. 42
3.7 Safety Application sPLC (User Program) ........................................................ 43
3.8 Standard Firmware PCCX25, PCCX26 and CPCX65 ...................................... 44

DC0-117-2.04, Edition 04.2015
Table of Contens
3.9 Safety Communication between BSE and Safety I/O Modules ........................ 45
3.10 Safety Communication between two Safety PLC’s .......................................... 46
3.10.1 Configuration of the Communication Channel ............................................ 48
3.10.1.1 Singular Communication Channel ......................................................... 48
3.10.1.2 Redundant Communication Channel .................................................... 49
3.10.2 Parameter Setting in the User Program (CAEx plus) .................................. 51
3.10.2.1 Configuration Parameters ..................................................................... 51
3.10.2.1.1 Assignment of the Remote Station ................................................... 51
3.10.2.1.2 Definition of the Timing Behavior ..................................................... 52
3.10.2.1.3 Change of Parameter Values during Operation ................................ 53
3.10.2.2 Simulation Mode................................................................................... 53
3.10.2.3 Assignment of the Process Data ........................................................... 53
3.10.2.4 Operating State of the Remote Station.................................................. 54
3.10.2.5 Communication Status.......................................................................... 54
3.10.3 Transmission of the Process Data ............................................................. 55
3.10.3.1 Periodical with Settable Grid ................................................................. 55
3.10.3.2 Spontaneous Controlled by Application................................................. 55
3.10.3.3 Timing Behavior ................................................................................... 56
3.10.4 Transmission Protection ............................................................................ 57
3.10.4.1 Protection by PROFIsafe ...................................................................... 57
3.10.4.2 Data Topicality with Watchdog Function ............................................... 57
3.10.4.3 Retry Handling with Communication Faults ........................................... 57
3.10.4.4 Safe State with Communication Failure ................................................ 57
3.10.5 Diagnostic Function for Error Detection...................................................... 58
3.10.5.1 Behavior with System Errors................................................................. 58
3.10.5.2 Behavior with Communication Errors .................................................... 59
3.10.6 Requirements on the User Program........................................................... 60
3.11 Basic System Element CP-2016 for SICAM AK 3............................................ 61
3.12 Basic System Element CP-2014 for SICAM AK .............................................. 61
3.13 Basic System Element CP-2019/PCCX26 SICAM AK 3 .................................. 62
3.14 Basic System Element CP-2017/PCCX25 SICAM AK ..................................... 63
3.15 Basic System Element CP-6014/CPCX65 SICAM TM..................................... 64
3.16 PE-641x/USIO66 Peripheral Coupling Module ................................................ 65
3.17 Safety I/O Modules ......................................................................................... 66
3.17.1 Introduction ............................................................................................... 66
3.17.2 Basic Concept ........................................................................................... 66
3.17.3 Addressing the Safety I/O Modules ............................................................ 66
3.17.4 Monitoring the Supply Voltage ................................................................... 67
3.17.5 DI-6170 ..................................................................................................... 67
3.17.6 DO-6270 ................................................................................................... 67
3.17.7 AI-6370 ..................................................................................................... 68
4 Safety System Configuration ...................................................................................... 69
4.1 SICAM AK 3 with Electrically & Optically Coupled PE's................................... 70

DC0-117-2.04, Edition 04.2015
Table of Contens
4.2 SICAM TM with Electrically and Optically Coupled PE's .................................. 71

4.3 Safety Communication between two SICAM AK.............................................. 72
4.4 Redundant Safety-PLC‘s with singular Periphery ............................................ 73
4.5 Redundant Safety-PLC‘s mit redundant Periphery .......................................... 74
5 Workflows for working with SICAM Safety ................................................................ 75
5.1 Introduction .................................................................................................... 76

5.2 Workflow for Application Development ............................................................ 77
5.2.1 Identify Application by means of Code Fingerprints .................................... 77
5.3 Design Plant ................................................................................................... 79
5.4 Install Hardware ............................................................................................. 80
5.5 Engineering .................................................................................................... 81
5.5.1 Define Plant and Automation Unit .............................................................. 82
5.5.2 HW/FW Configuration of Automation Unit .................................................. 82
5.5.3 Set Parameters ......................................................................................... 83
5.5.4 Create Application and generate Code ...................................................... 83
5.5.5 Simulate Function Chart Offline ................................................................. 85
5.6 Verification of the Application.......................................................................... 86
5.6.1 Definitions for the State of "Verification" ..................................................... 87
5.6.2 Review of the Application........................................................................... 87
5.7 Download of the Application to the Controller .................................................. 89
5.8 Online Test of the Application ......................................................................... 91
5.9 Validation of the Application............................................................................ 92
5.9.1 Definitions for the State of "Validation" ....................................................... 93
5.10 Release of the Application and Operation Preparation .................................... 94
5.10.1 Release of the Application ......................................................................... 94
5.10.2 Operation Preparation for the Released Application ................................... 96
5.11 Operation ....................................................................................................... 98
5.11.1 Restart of the Automation Unit ................................................................... 98
5.11.2 Set Plant in Operating Mode STOP............................................................ 99
5.11.3 Set Plant in Operating Mode TEST ............................................................ 99
5.11.4 Set Plant in “safe” Operating Mode RUN.................................................. 100
5.12 Maintenance................................................................................................. 101
5.12.1 Exchange Basic System Element ............................................................ 101
5.12.2 Exchange Safety I/O Modules.................................................................. 103
5.12.3 Exchange SD Card .................................................................................. 103
5.13 Workflow for the Software Modifications ....................................................... 105
5.13.1 Workflow with complete Verification/Validation ......................................... 105
5.13.2 Workflow with Delta Examination ............................................................. 106
5.13.3 Identify Versions of Application by means of Code Fingerprints................ 107
5.13.3.1 Identify Version "A" of Application ....................................................... 108
5.13.3.2 Identify Version "B" and "C" of Application .......................................... 109
5.13.4 Re-engineering in the Programming System ............................................ 109
5.13.5 Download of the Application to the Controller ........................................... 109

DC0-117-2.04, Edition 04.2015
Table of Contens
5.13.6 Delta Examination of the Application........................................................ 110

5.13.7 Release of the Application and Operation Preparation ............................. 111
5.13.7.1 Release of the Application .................................................................. 111
5.13.7.2 Operation Preparation for the released Application ............................. 111
5.14 Commissioning of redundant Safety-PLC's ................................................... 112
6 Operating Modes ....................................................................................................... 115
6.1 Safe Operation ............................................................................................. 116

6.2 Operating Modes .......................................................................................... 117
6.2.1 RUN ........................................................................................................ 117
6.2.2 STOP ...................................................................................................... 118
6.2.3 TEST....................................................................................................... 118
6.2.4 KILL ........................................................................................................ 118
6.3 Startup ......................................................................................................... 119
6.4 Setting the Operating State with SICAM TOOLBOX II ................................... 120
6.5 Display of the Operating State ...................................................................... 121
6.5.1 SICAM AK 3 ............................................................................................ 121
6.5.2 SICAM AK ............................................................................................... 122
6.5.3 SICAM TM .............................................................................................. 123
6.6 Status of the Subsystems for each Operating State ...................................... 124
6.7 Permitted Operator Inputs ............................................................................ 125
6.8 Operating States of the I/O Modules ............................................................. 126
7 Error Detection and Management............................................................................. 127
7.1 Introduction .................................................................................................. 128

7.2 Error Classes ............................................................................................... 129
7.3 System Errors .............................................................................................. 130
7.3.1 System Errors on the Basic System Element ........................................... 130
7.3.2 System Errors on the I/O Modules with Inputs.......................................... 131
7.3.3 System Errors on the I/O Modules with Outputs ....................................... 131
7.4 Channel Errors ............................................................................................. 132
7.4.1 Channel Errors on the Basic System Element .......................................... 132
7.4.2 Channel Errors on the I/O Modules with Inputs ........................................ 132
7.4.3 Channel Errors on the I/O Modules with Outputs...................................... 132
7.4.4 Behavior with Channel Errors .................................................................. 133
7.4.4.1 User Program ..................................................................................... 134
7.4.4.2 Automatic without Restart Inhibit ......................................................... 135
7.4.4.3 Automatic with Restart Inhibit.............................................................. 136
7.5 Diagnostics .................................................................................................. 137
7.5.1 Standard Diagnostics .............................................................................. 137
7.5.2 LED Display ............................................................................................ 137
7.6 Measures of CAEx Safety for Fault Avoidance and/or Detection ................... 138
7.6.1 Authentication Measures ......................................................................... 138

DC0-117-2.04, Edition 04.2015
Table of Contens
8 System Response Time ............................................................................................ 141
8.1 General ........................................................................................................ 142

8.1.1 Input and Output within a Basic System Element ..................................... 142
8.1.2 Input and Output via Distributed Basic System Elements / Automation Units142
9 Safety Parameters ..................................................................................................... 145
9.1 Safety SICAM RTUs Parameters .................................................................. 146

9.1.1 Configuration and Consistency Parameters of the Safety Application ....... 146
9.1.2 Configuration Parameters of the Safety Application.................................. 146
9.1.3 DI-6170 ................................................................................................... 147
9.1.3.1 Parameter: Test_Cycling_Group_SAFE .............................................. 147
9.1.4 DO-6270 ................................................................................................. 148
9.1.4.1 Parameter: Relay_Type_SAFE ........................................................... 148
9.2 Safety PLC Parameters ................................................................................ 150
9.2.1 Safety Application AP-0771/SPLC01 ....................................................... 150
9.2.1.1 Parameter: Safe State with Channel Errors......................................... 150
9.3 Standard SICAM RTUs Parameters.............................................................. 151
9.3.1 CP-2017 / CP-6014 ................................................................................. 151
9.3.1.1 Parameter: Failure Behavior ............................................................... 151
10 Technical Data........................................................................................................... 153
10.1 Total System ................................................................................................ 154

10.1.1 Electrical Environmental Conditions ......................................................... 154
10.1.2 Climatic Environmental Conditions........................................................... 154
10.1.3 Mechanical Environmental Conditions ..................................................... 154
10.2 Safety I/O Modules ....................................................................................... 155
10.2.1 Mechanical Environmental Conditions ..................................................... 155
10.2.2 Climatic Environmental Conditions........................................................... 155
10.2.3 Climatic Tests .......................................................................................... 156
10.2.4 Electrical Environmental Conditions ......................................................... 156
10.3 Safety-Technical Characteristic Values ......................................................... 157
10.3.1 MTBF ...................................................................................................... 157
10.3.2 Repeat Testing Interval............................................................................ 157
10.4 Declarations of Conformity............................................................................ 159
11 Guidelines for Programming .................................................................................... 161
11.1 General ........................................................................................................ 162

11.2 Project Structure........................................................................................... 163
11.3 Logic ............................................................................................................ 164
11.4 POU Interface resp. Global Variable ............................................................. 165
11.5 Modifications in the Safety Application .......................................................... 166
11.6 Supported CAEx plus Data Types and Blocks............................................... 168
11.6.1 Elementary Data Types ........................................................................... 168

DC0-117-2.04, Edition 04.2015
Table of Contens
11.6.2 Safety Data Types ................................................................................... 168

11.6.3 Supported IEC Blocks ............................................................................. 169
11.6.4 Safety Blocks .......................................................................................... 170
11.6.5 Safety Conversion Blocks ........................................................................ 170
11.7 Basis for your own Guidelines ...................................................................... 171
11.7.1 Reserved Keywords according to IEC ...................................................... 171
11.8 Application Notes ......................................................................................... 175
11.8.1 Behavior of the Module Outputs when using the EN Input ........................ 175
A Checklists .................................................................................................................. 177
A.1 Planning ....................................................................................................... 177

A.2 Programming................................................................................................ 178
A.3 Installation .................................................................................................... 179
A.4 Commissioning............................................................................................. 179
A.5 Maintenance, Modification ............................................................................ 181
B Installation Declaration ............................................................................................. 183
C TÜV Certificate .......................................................................................................... 187

DC0-117-2.04, Edition 04.2015
1 Principles of Functional Safety
Contents
1.1 Introduction .................................................................................................... 14

1.2 Legal Basis..................................................................................................... 15
1.3 Machinery Directive ........................................................................................ 16
1.4 Standards for Construction and Risk Assessment ........................................... 17
1.5 Standards for Safety-related Controllers ......................................................... 18
1.6 IEC 61508 – Basic Standard........................................................................... 19
1.7 IEC 62061 ...................................................................................................... 20
1.8 EN ISO 13849 ................................................................................................ 21
1.9 EN 5012x ....................................................................................................... 22

DC0-117-2.04, Edition 04.2015
Principles of Functional Safety
1.1 Introduction
Operators of machines are obliged by the legislator to ensure for the safety of people and the
environment. For this purpose all rules, regulations and ordinances valid at the operating
location are to be applied. If a potential hazard exists, a hazard and risk analysis must be
carried out. In this the risks present are described and existing as well as additional measures
defined for their reduction. The residual risk remaining must always be below the tolerable
level.
One defines that state that is free of unjustifiable risks for humans or regarded as free of
hazards as the overall safety of a machine.
The Functional Safety describes that part of the overall safety of a system that is dependent
on the correct function of the safety-related systems and external equipment for the reduction
of risks. In case of need these parts must be able to bring the entire system to the safe state
at all times.
The parts of machine controllers that perform safety tasks are known in the international
standards as “Safety-related parts of controllers”. These parts can consist of hardware and/or
software and be separate or integral components of the machined controller.
Safety-related controller parts in each case include the entire chain of effects of a safety
function, consisting of the Input level (sensor), the Logics (safe signal processing) and the
Output level (actuator).
The general objective is to design these controller parts so that the safety of the controller
function as well as the behavior of the controller in the case of error corresponds with that
degree of risk reduction determined in the risk assessment.
Therefore the higher the risk reduction to be provided by the safety-related controller part is,
the higher the required safety class or the safety-related performance level of the controller
part.
Note
It is pointed out, that besides those points listed in this Safety Manual, requirements going beyond this are
also to be fulfilled. These are the legislative, national requirements or requirements from the Machinery
Directive (e.g. Attachment I).

DC0-117-2.04, Edition 04.2015
1.2 Legal Basis
One of the measures for the realization of the free movement of goods in Europe is the
adaptation of the technical legal regulations to a Europe-wide uniformly formulated standard.
For this purpose the Council of the EU issues directives according to Article 95 of the EC
Treaty concerning the harmonization of the technical product requirements (e.g. Machinery
Directive 2006/42/EC).
As regards content these directives must be implemented 1:1 in national law by the member
states. As a sign of the conformity with a manufacturer directive the manufacturer attaches the
CE identification symbol to every product.

DC0-117-2.04, Edition 04.2015
1.3 Machinery Directive
The Machinery Directive 2006/42/EC regulates the free movement of goods for machines,
machine installations, and machine components in the European Economic Area (EEA). It
specifies binding uniform requirements on the quality and on the method for the assessment
of the conformity.
The aim is the free movement of goods for safe machines in the European Economic Area.
What is a machine?
· The entirety of parts connected together, of which at least one is movable

· It is used for a particular application
· It has a drive system or is intended for this purpose
How can the observance of the Machinery Directive be ensured?
· Machine acceptance by an inspection authority

· Fulfillment of the harmonized standards
· Sole safety evidence with increased inspection and documentation work
In every case the CE identification symbol with corresponding safety evidence is the visible
proof for the fulfillment of the Machinery Directive. According to the EU Framework Directive
for Occupational Safety it is specified as binding.

DC0-117-2.04, Edition 04.2015
1.4 Standards for Construction and Risk Assessment
· EN ISO 12100-1 Safety of Machinery (basic concepts, general principles for design)
· EN ISO 14121-1 Safety of Machinery
Risk assessment – Part 1: Principles
It is explained in these standards, according to which principles and methods a risk

assessment, risk analysis and risk minimization is to take place. These standards are
harmonized and therefore particularly helpful for the European Jurisdiction.
From these result functional and safety-relevant requirements for safety-related controllers.

DC0-117-2.04, Edition 04.2015
1.5 Standards for Safety-related Controllers
· IEC 62061: Edition 2006-08-01 Identical (IDT) with EN 62061:2005

Safety of Machinery – Functional safety of safety-related electrical, electronic and
programmable logic electronic control systems
· EN ISO 13849: Edition 2009-09-01, ISO 13849-1: 2006 + Cor 1: 2009
Safety of Machinery – Safety-related parts of control systems
· IEC 61508 Edition 2.0, Edition 2010-04
Functional safety of safety-related electrical/electronic/programmable electronic systems
· EN 50126: Edition 2000-05-01, Ident (IDT) with EN 50126:1999
Railway applications -
The specification and demonstration of reliability, availability, maintainability and safety
(RAMS)
· EN 50128: Edition 2001
Communication, signalling and processing systems -
Software for railway control and protection systems
· EN 50129: Edition 2003
Communication, signalling and processing systems -
Safety related electronic systems for signalling
· EN 50159-1
Communication, signalling and processing systems;
Part 1: Safety-related communication in closed transmission systems - 2001
· IEC 61511 (ed. 1)
Functional safety - Safety instrumented systems for the process industry sector
These standards provide methods and requirements, in order to determine the required safety
integrity level for every safety-related control system function.

DC0-117-2.04, Edition 04.2015
1.6 IEC 61508 – Basic Standard
Functional safety of safety-related electrical/electronic/programmable electronic

systems.
This international standard deals with those aspects that are to be considered, when
electrical/electronic/programmable electronic systems (E/E/PES) are used for the execution of
safety functions.
The IEC 61508 standard defines four different levels of safety. These describe measures for
the management of risks with the components used, that are rated by the so-called Safety
Integrity Level. The higher this is, the greater is the risk reduction. With that the SIL is the
measure for the probability, that the safety-related system can fulfill the required safety
functions for a particular period.

DC0-117-2.04, Edition 04.2015
1.7 IEC 62061
Safety of Machinery – Functional safety of safety-related electrical, electronic and

programmable electronic control systems
The EN 62061 standard defines extensive requirements. It provides recommendations for the
design, integration and validation of safety-related electrical, electronic as well as
programmable electronic control systems (SRECS) for machines.
It considers for the first time the entire safety chain from sensor to actuator. In order to
achieve a Safety Integrity Level such as perhaps SIL 3, it is no longer sufficient that the
individual components are certified accordingly. On the contrary, the entire safety function
must satisfy the defined requirements.
This standard classifies the systems according to SIL (Safety Integrity Level)
Safety Integrity Level Probability of a dangerous failure per hour (PFHD)

-6 -5
SIL 1 ≥ 10 to <10
-7 -6
SIL 2 ≥ 10 to <10
-8 -7
SIL 3 ≥ 10 to <10

DC0-117-2.04, Edition 04.2015
1.8 EN ISO 13849
Safety of Machinery – Safety-related parts of control systems.

Part 1: General principles for design
This part of the EN ISO 13849 provides safety requirements and a guideline for the principles
of design and integration of safety-related parts of control systems (SRP/CS), including the
development of software. For these parts of the SRP/CS characteristics are defined, including
the Performance Level, that are required for the execution of the corresponding safety
functions. It is to be applied to SRP/CS on all types of machines, regardless of the technology
and energy used (electrical, hydraulic, pneumatic, mechanical etc.).
This standard classifies the systems according to PL (Performance Level)
· PL a – lowest safety level (produces SIL0)

· PL b - (produces SIL1)
· PL c - (produces SIL1)
· PL d - (produces SIL2)
· PL e – highest safety level (produces SIL3)
ISO 13849-2 Safety of Machinery – Safety-related parts of control systems.

Part 2: Validation
This European standard defines the validation procedure, including the two methods Analysis
and Inspection, for the safety functions and categories of safety-related parts of control
systems.

DC0-117-2.04, Edition 04.2015
1.9 EN 5012x
Railway applications - Communication, signalling and processing systems.
This group of standards classifies the systems according to Safety Integrity Level - SIL and
essentially refers to the standard EN 61508. It consists of 3 essential standards:
· EN 50126: The specification and demonstration of reliability, availability, maintainability

and safety (RAMS)
· EN 50128: Software for railway control and protection systems
· EN 50129: Safety related electronic systems for signalling
· EN 50159-1: Safety-related communication in closed transmission systems - 2001
Note
For the use of SICAM RTUs with the Safety function it is necessary to guarantee the compliance with the
specified environmental conditions, according to the application classes defined in the standards
EN 50121, EN 50124 and EN 50125. This is accomplished by means of surrounding structure (e.g. wall-
cabinet, 19” cabinet).
For monitoring the operating temperature, an external temperature monitoring system, e.g. AI-6310 analog
input 2x2 Pt100/Ni100, must be used during the operation of SICAM RTUs with the Safety function.
The actual operating temperature must be evaluated by the application. In the event of non-compliance
with the specified temperature range, the application must derive safety-related measures.

DC0-117-2.04, Edition 04.2015
2 Functional Safety with SICAM RTUs
Contents
2.1 Introduction .................................................................................................... 24

2.2 Achievable Safety Classes ............................................................................. 25
2.3 Safety Components of SICAM RTUs .............................................................. 26
2.4 Proper Intended Use ...................................................................................... 28
2.5 General Safety Assessment ........................................................................... 29

DC0-117-2.04, Edition 04.2015
Functional Safety with SICAM RTUs
2.1 Introduction
The SICAM RTUs automation concept provides suitable components in order to fulfill the
safety classes determined in a risk assessment. This takes place with a concept, with which
the process information from the sensors is processed 2-channel via the control system
through to the actuators.
· All Safety I/O modules are constructed two-channel internally. The two integrated
processors process the firmware in parallel, monitor each other, detect errors and with the
occurrence of an error, switch immediately to a safe state and remain in that state.
· There is a separation between standard and safety-oriented automation tasks.
· The communication between a safety-oriented control system as well as assigned safety-
oriented periphery takes place via the PROFIsafe protocol.
· The communication between two safety-oriented applications takes place via the
PROFIsafe protocol.
· The creation, verification and validation of the safety control systems is carried out with the
CAEx safety-Toolset of the SICAM TOOLBOX II.
· The editing of the safety parameters is carried out with the OPM II. The verification and
validation of the safety parameters is carried out with the CAEx safety Toolset of the
SICAM TOOLBOX II.
· The generation of the user program takes place with the CAEx plus Toolset.
This concept was realized in the products SICAM AK and SICAM TM with the function SICAM
Safety.

DC0-117-2.04, Edition 04.2015
2.2 Achievable Safety Classes
With suitable parameterization of the safety control system as well as by means of a particular
arrangement and wiring of suitable sensors and actuators, the following safety classes can be
achieved:
2.2.1 Overall System
Standard Safety Integrity Level (SIL) Performance Level PL

IEC 61508 SIL 2 -
IEC 62061 SIL 2 -
EN ISO 13849 - PL d; Kat. 3
EN 50126[2] SIL 2
EN 50128[4]
EN 50129[3]
EN 50159-1[5]
2.2.2 Modules
Modules IEC 61508 IEC 62061 EN ISO 13849 EN 5012x

CP-2019/SPLC01 SIL 2 SIL 2 PL d, Cat 3 SIL 2
DI-6170 SIL 3 SIL 3 PL d, Cat 4 SIL 3
DO-6270 SIL 3 SIL 3 PL d, Cat 4 *) SIL 3
PL d, Cat 3 **)
AI-6370 SIL 2 SIL 2 PL c, Cat 4 SIL 2
*) for relay without electronics

**) for relay with electronics

DC0-117-2.04, Edition 04.2015
2.3 Safety Components of SICAM RTUs
2.3.1 System Overview
The following picture shows an overview of those components that are required for the
construction and operation of a failsafe SICAM RTUs automation system.
Example 1: SICAM AK 3 (AU1) with safety communication to SICAM TM peripheral

elements and with safety communication to higher-level automation unit
(AU2)
SICAM TOOLBOX II
with toolset „CAEx safety“
SICAM AK
with basic system
AU2
element
TOOLBOX II
Rev ision:
Li cense Pa k:
CP-2017/PCCX25
Version 5 | S ie mens AG
and safety-firmware
AP-0771/SPLC01
Safety communication
SICAM AK 3
with basic system
AU1
element
CP-2019/PCCX26
and safety-firmware
AP-0771/SPLC01
Safety communication with PROFIsafe layer

via Ax 1703 peripheral bus and TM bus.
SICAM TM peripheral elements (PE-641x/USIO66)

with safety I/O-modules
up to 16 peripheral elements possible

DC0-117-2.04, Edition 04.2015
Beispiel 2: SICAM TM with safety communication to SICAM TM peripheral elements
SICAM TOOLBOX II SICAM TM

with toolset „CAEx safety“ with basic system element
CP-6014/CPCX25
and safety-firmware
AP-0771/SPLC01
TOOLBOX II
Rev ision:
Li cense Pak:
Version 5 | Siemens AG
CP-6014
T M 1703 ACP
SICAM
Secure communication with PROFIsafe layer
via Ax 1703 peripheral bus and TM bus.
SICAM TM peripheral elements (PE-641x/USIO66)

with safety I/O-modules
up to 16 peripheral elements possible
2.3.2 Safety Components
Type Designation Description

Firmware AP-0771/SPLC01 Safety-Firmware; can be loaded on basic system element :
· CP-2019/PCCX26
· CP-2017/PCCX25
· CP-6014/CPCX65
I/O Module DI-6170 Binary input module; 8 digital inputs; 24 VDC signal voltage
I/O Module DO-6270 Binary output module; 4 digital outputs; 24 VDC signal voltage
I/O Module AI-6370 Analog input module; 4 analog inputs; 4-20 mA
Toolset CAEx safety Expansion of the TOOLBOX with the tools:
· Safety V&V
· Safety Monitor

DC0-117-2.04, Edition 04.2015
2.4 Proper Intended Use
The objective of the safety technology is to keep the endangering of people and the
environment through technical equipment as little as possible, without restricting the industrial
production and the use of machines more than is absolutely necessary in this process.
SICAM RTUs systems with safety components can be used everywhere, where the risk
assessment has resulted in that the use is possible and the safe state is brought about by
“switching the voltage off”.
A typical case of application is the use in hydroelectric power stations for the protection of
turbines and generators from impermissible mechanical stressing.
Other scopes of application are automation tasks in the fields of oil, gas and railways.
SICAM RTUs are NOT suitable for use e.g. in:
· Automation systems with increased requirements on the environment (e.g. potentially

explosive areas).
· Automation systems for which the switch off of a voltage does not lead to the safe state.
· Automation systems for which SIL 3 or higher is required.
· Automation systems for which a Performance Level PL e or higher is required.
· Railway applications within the 3 m range.
· Systems for the transportation of passengers

DC0-117-2.04, Edition 04.2015
2.5 General Safety Assessment
Before the implementation of a SICAM RTUs Safety System a safety assessment according
to the Machinery Directive is necessary. A SICAM RTUs Safety System as single component
is a safety-related system in the sense of EN/IEC 61508. It guarantees functional safety
against errors in the hardware and firmware. However it does not guarantee the safety of the
entire process as well as the planning of the project.
The user is responsible for the safety of the project. Proceed with particular care when
programming and observe the regulations and standards valid for the place of use.
A faulty control system can nullify the safety of the entire process!
Define the safety requirements for the entirety of the machine, for all service life phases and
the entire safety life cycle and how they are to be realized technically and organizationally.
Technical Measures
The technical measures include e.g. the use of the SICAM RTUs safety components and the
planning and creation of the project with the CAEx safety Toolset of the SICAM TOOLBOX II.
Organizational Measures
One regards organizational measures as e.g. the determination of the personnel responsible
or the documentation of all work steps for the setting into operation. That also includes
determinations regarding responsibilities and access rights. The safety requirements are
governed by the function of the machine and the hazards resulting therefrom. Malfunctions
and maloperation and the possible consequences must also be included in a safety
assessment.
2.5.1 Safety Assessment of SICAM RTUs
SICAM RTUs are suitable both for standard as well as safety applications.
There are:
· Standard and Safety Modules
· Standard and Safety Modules in the SICAM TOOLBOX II
· Standard and Safety Communication Channels
· Standard and Safety PLC
The safety-related tasks must only be programmed with safety modules. For the programming
of safety modules the user can also simply access standard data types. To do this the safety
data types must only be connected in series to an upstream "converter module".
Note
The standard data types and standard modules must not influence the safe shutdown.
The following points are the responsibility of the user:

· Selection of the suitable safety modules
· Correct I/O assignment
· Correct use of safety modules
· Correct choice of the safety data types

DC0-117-2.04, Edition 04.2015
· Correct use of the "converter module"
2.5.2 Types of Error, Error Detection and Error Reaction in

SICAM RTUs
Basically a distinction is made between random errors and systematic errors.
The random types of error include e.g. the inversion of a bit in the memory or during the data
transmission.
The systematic types of error include errors in the firmware or hardware. This concerns either
logical errors due to faulty information (e.g. false allocation of a data type) or also errors that
first have an effect due to certain boundary conditions in the program sequence (memory
overflows, boundary conditions not taken into account etc.).
SICAM RTUs have various functions for the detection of errors (diagnostic functions),
whereby a detected error always leads to a defined error reaction.
Note
The error reaction of the system can be determined through parameter setting.
The 2-channel design of the safety modules and the various other measures for error
detection and error reaction provide a high level of safety. It must be ensured during planning,
configuration and user programming, that this high level of safety is not nullified through errors
and negligence.
Note
Programming errors in the user program cannot be detected.
2.5.3 Data Saving and Data Security in SICAM RTUs
2.5.3.1 Data Saving
The aim of the data saving is the securing of data against loss.
All SICAM RTUs parameters, applications and firmware are managed and stored centrally in
the SICAM TOOLBOX II. The tool "Data Distribution Center" provides the possibility to secure
these data by means of a backup.
The following engineering data can be exported / imported in the Data Distribution Center.
· Customer (Plant Management, User • incl. Presets)

· System Technique (Regions and Automation Units)
· Process Technology (Ranges, Display Overview of the Image Parameterization
SICAM BC, CAEx plus Project Library)
· Master Data
· PSRII Data (Recorder Recordings, Customer Parameters and Customer Filters,
Disturbance Event Data, Transmit Menus)

DC0-117-2.04, Edition 04.2015
· Logbook Data
· Information for Verification and Validation
2.5.3.2 Data Security
One regards data security as the security of data with respect to availability, integrity and
confidentiality.
In SICAM RTUs various mechanisms are used for data security. A distinction is made
between technical measures and organizational measures.
Technical Measures
The technical measures contribute towards data security as regards errors and faults. They
intervene automatically, as soon as the data are exposed to a corresponding influence. The
technical measures include e.g.:
· 2-channel acquisition and processing of secure signals

· Backup procedure during the download of a project
· Safety in the protocol for the data transmission with PROFISafe
· Interference immunity
· Detection of safety applications with different revisions
The target revision of the safety application is stored in the safety parameters. Following
the safety approval, this prevents another, unapproved revision of the safety application
being loaded.
· Defective or missing SD cards are indicated by means of a diagnostic information. This
has no influence on the rest of the operation.
Warning
If an SD card is exchanged, a repeat commissioning must be carried out.
· Allocation of an access authorization for all safety-related activities in

SICAM TOOLBOX II.
Organizational Measures
The organizational measures contribute towards data security as regards inadvertent or

intentional manipulation of data. The user is mainly responsible for the implementation of
suitable organizational measures.
· Security
It is advisable to develop a comprehensive strategy with regard to security measures.
Falling under security are all criteria that concern the integrity, availability, confidentiality,
reliability, operational safety and authenticity of data.
The security measures include e.g.:
─ The authentication, the password administration and the access authorization to

networks and LAN segments, above all also in respect of the access security for
remote maintenance in Ethernet-based networks
─ Logical and functional segregation of office and automation environment for Ethernet-
based networks e.g. through Firewalls

DC0-117-2.04, Edition 04.2015
· Verification, Validation and Enabling

The work with SICAM RTUs requires the observance of the V&V model. This requires that
all safety-relevant parameters must be verified, validated and enabled. These activities
must be performed by the user with the "Safety V&V" Tool. A safety application can only
then reach the operating state RUN when the enabling of the parameters has taken place.

DC0-117-2.04, Edition 04.2015
3 Safety System Description
Contents
3.1 Concept.......................................................................................................... 34
3.2 Safety Functions............................................................................................. 38
3.3 Segregation of Safe and Standard Firmware................................................... 39
3.4 Recognizability of Safety Product Components ............................................... 40
3.5 System Limits ................................................................................................. 41
3.6 Safety Firmware AP-0771/SPLC01 ................................................................. 42
3.7 Safety Application sPLC (User Program) ........................................................ 43
3.8 Standard Firmware PCCX25 and CPCX65 ..................................................... 44
3.9 Safety Communication between BSE and Safety I/O Modules ........................ 45
3.10 Safety Communication between two Safety PLC’s .......................................... 46
3.11 Basic System Element CP-2014 for SICAM AK .............................................. 61
3.12 Basic System Element CP-2017/PCCX25 SICAM AK ..................................... 62
3.13 Basic System Element CP-6014/CPCX65 SICAM TM..................................... 64
3.14 PE-641x/USIO66 Peripheral Coupling Module ................................................ 65
3.15 Safety I/O Modules ......................................................................................... 66

DC0-117-2.04, Edition 04.2015
Safety System Description
3.1 Concept
As a basis of the safety concept a safe state has been defined for all process variables, which
is assumed in the case of error. This “safe state” is the state of the entire system without
current and voltage.
In the safe state:

· All outputs of the safety I/O modules are terminated
· All safe inputs (digital and analog) in the safety application are set to 0
The SICAM RTUs system is grouped into the SICAM TOOLBOX II working offline and the
online system SICAM AK, consisting of basic system elements and I/O modules, which
communicate with each other over a bus.
The SICAM RTUs Safety Concept, from the acquisition of the sensors and the processing
through to output at the actuator is achieved in the following way:
· Periodical acquisition of the process data at the safety input modules

· 2-channel acquisition and processing of the process data on the safety I/O modules.
· Forwarding to the basic system element over a communication route secured by a failsafe
transmission protocol.
· Here the diverse processing of the 2-channel process data provided is carried out
periodically by the safe open-/closed loop control function (safety application).
· The calculated process data are forwarded to the safe output modules over the secure
communication and output by these to the process.
· The communication between two safety-oriented applications

DC0-117-2.04, Edition 04.2015
Example 1: SICAM AK 3 or SICAM AK with safety communication to SICAM TM

peripheral elements
further automation unit further automation unit
Processing and
*)
Communication communication element Communication
Protocol element(s) Protocol element(s)
Safety firmware
AP-0771/SPLC01
Node bus PLC standard
open-/closed-loop sPLC safety
control function open-/closed-loop
control function
Safety Layer
**)
Master control element
Safety Layer
Peripheral control Safety I/O modul

module DI-6170, DO-6270, AI-6370
PE-641x
PBA# IOM#
TM bus
periodical safety data
Safety Layer
spontaneous data
Ax Peripheral bus
Firmware
USIO66 Peripheral
interfacing
Process
further
peripheral elements
*) **)
CP-2019/PCCX26 (SICAM AK 3) CP-2016/CPCX26 (SICAM AK 3)
CP-2017/PCCX25 (SICAM AK) CP-2014/CPCX25 (SICAM AK)

DC0-117-2.04, Edition 04.2015
Example 2: SICAM TM with safety communication to SICAM TM peripheral elements
further automation unit

CP-6014/CPCX65 Communication
Protocol element(s)
Safety firmware
AP-0771/SPLC01
PLC standard
open-/closed-loop sPLC safety
control function open-/closed-loop
control function
Safety Layer
Safety Layer
Peripheral control Safety I/O modul

module DI-6170, DO-6270, AI-6370
PE-641x
PBA# IOM#
TM bus
periodical safety data Safety Layer
spontaneous data
Ax Peripheral bus
Firmware
USIO66 Peripheral
interfacing
Process
further
peripheral elements

DC0-117-2.04, Edition 04.2015
Example 3: SICAM AK 3 or SICAM AK (AU1) with safety communication to SICAM TM

peripheral elements and with safety communication to higher-level
automation unit (AU2)
**)
Master control element Processing and
communication element
*) AP-0771/SPLC01
sCM sPLC safety

Node bus
AU2
PLC standard
SL
Safety Layer

Protocol element Protocol element(s)
SL
SL
Processing and
*)
Protocol element communication element Protocol element(s)
Safety Layer
SL
AP-0771/SPLC01
AU1
PLC standard
Node bus
sPLC safety sCM
Safety Layer
**)
Safety Layer
SICAM TM I/O Modules
PE-641x DI-6170, DO-6270, AI-6370
TM bus
Ax Peripheral bus
spontaneous data
Peripheral
USIO66 interfacing
further Process
peripheral elements
*) **)

DC0-117-2.04, Edition 04.2015
3.2 Safety Functions
Safety functions have the task of holding the system in the safe state or bringing it to the safe
state. These functions for the error detection and error reaction are contained in the safety
firmware and the safety I/O modules. They monitor the periodical processing of the process
information and the I/O modules for internal errors or external circuitry faults.
The following safety functions are performed:
· Periodical Safety Functions

· Integrated Error Monitoring in the Safety Firmware (SPLC01)
· Integrated Error Monitoring in the Safety I/O Module
· Error Detection on the Peripherals (external circuitry)
3.2.1 Periodical Safety Functions
· Periodical acquisition of process information on the safety I/O modules and forwarding to
the safety application
· Periodical processing of process information by the safety application with settable cycle
time
· Forwarding of the process information calculated by the safety application to the safety
output modules and output to the peripherals.
3.2.2 Integrated Error Monitoring in the Safety Firmware (SPLC01)
· Failure of the safety open- and closed loop control function (sPLC)
· Access protection to safety-critical user programs and parameters
· Failure of the data flow
· Error detection by means of self-tests
· Error/failure in the I/O modules by the safety layer
· Logical program sequence monitoring
· Errors in the communication with the I/O modules by the safety layer
3.2.3 Integrated Error Monitoring in the Safety I/O Module
· Failure of the basic system element or the safety firmware

· Failure of the data flow
· Error detection by means of self-tests
· Restart protection
· Errors in the circuitry for Logics/Acquisition/Output
3.2.4 Secure Communication between SICAM Safety PLC’s
· Secure point-to-point connections between Safety PLC’s on various BSE’s for the
transmission of binary information and measured values
· Secure transmission of the operating status
· Secure communication for redundant Safety PLC’s

DC0-117-2.04, Edition 04.2015
3.3 Segregation of Safe and Standard Firmware
It is ensured through this segregation, that influencing of the safety-oriented functions by

“standard” functions is detected and that appropriate error reactions are triggered.
This principle ensures, that modifications or exchange of the “standard” firmware has no effect
on the safe firmware. As a result no repeat commissioning of the safety function is necessary
when the standard firmware is changed.

DC0-117-2.04, Edition 04.2015
3.4 Recognizability of Safety Product Components
All safety components of a SICAM RTUs system are unambiguously identifiable based on the
following features:
· Safety Hardware
─ yellow housing
─ yellow labeling plates on the safety I/O modules
─ yellow labeling stripes on CPU module
(processing and communication element CP-2017/PCCX25)
─ yellow safety-label on SICAM TM master control module
(CP-6014/CPCX65)
─ TÜV-Süd inspection symbol
─ Company address on the housing
· Safety Documentation
─ Unambiguous recognizability of safety-relevant components in graphics through yellow
marking.
· Safety Firmware
─ Safety modules in SICAM TOOLBOX II are yellow
─ Safety application (system element AP-0771/SPLC01 or node "Safety Applications" in
library overview) in SICAM TOOLBOX II is yellow.
─ Safety CAEx modules in SICAM TOOLBOX II are yellow
─ Safety parameters are indicated in the tool “Safety V&V”
· Safety Product Information

─ Safety-relevant products are marked in the product information system ISI-web with (S)
at the end of the designation.

DC0-117-2.04, Edition 04.2015
3.5 System Limits
Value / Qty
Maximum number of peripheral coupling elements in SICAM AK with function SICAM 16
Safety
Maximum number of peripheral coupling elements in SICAM TM with function SICAM 16
Safety
Maximum number of safety I/O modules per peripheral coupling element 8 *)
Maximum number of AI-6370 per peripheral coupling element 4
Maximum number of DO-6270 per peripheral coupling element 4
Maximum number of safety I/O modules 128
*) Only for modules with single module width.
When using modules with double module width (e.g. DO-6270) this number is reduced.
The peripheral element may be maximum 8 single module widths long.
Quantity structure of the sPLC (Safety open-/closed loop control function)

Maximum size of the user program (compiled code) 128 kB
Maximum size of the user program (interpreted code) 448 kB
Number of periodical tasks 1
Maximum number of type instances 32
Maximum number of spontaneous input messages 256
Maximum number of spontaneous output messages 256
Maximum number of safety connections between Safety-PLC‘s 127

DC0-117-2.04, Edition 04.2015
3.6 Safety Firmware AP-0771/SPLC01
The system element AP-0771/SPLC01 is installed in SICAM AK on the system element

CP-2017/PCCX25 and in SICAM TM on the system element CP-6014/CPCX65. The safety
application (open-/closed loop control function / function diagram) created with CAEx plus and
CAEx safety are stored on it.
This firmware contains safety mechanisms such as e.g.:
· Disable/Enable protection during the program run

· Double, diverse program processing
· CPU Test
· FPU Test (Floating Point Unit)
· RAM Test
· Code memory test and parameter memory test
· Stack Test
· PROFISafe mechanisms
For securing the data transmission between the safety application and the safety I/O
modules the PROFIsafe protocol (IEC 61784-3-3) is used.
· Separate memory ranges protected with an MMU
· Logical program run monitoring
· Chronological program run monitoring

DC0-117-2.04, Edition 04.2015
3.7 Safety Application sPLC (User Program)
The safety open-/closed loop control function (sPLC) for automation functions is created with
CAEx plus in function diagram technology.
The maximum achievable system response time of a safety application (from the change of
the input signal until output of the tripping signal) is 100 ms.
The processing of the safe user program takes place diversely over 2 channels.
The following signals are processed:
· Safety periodical information (2-channel)

· Spontaneous information objects
Note
Standard periodical information are not available on an sPLC.
The sPLC runs parallel to the standard open-/closed loop control function (PLC).

DC0-117-2.04, Edition 04.2015
3.8 Standard Firmware PCCX25, PCCX26 and CPCX65
This firmware contains:
· Communication Functions
─ Organization of the data flow to the communication interfaces
─ Data storage in target-selective process images
─ Priority control
─ Spontaneous serial communication via up to 4 independent serial interfaces or
spontaneous LAN/WAN communication over Ethernet to optional higher- or lower level
automation units
· Node Functions (only PCCX26, PCCX25)
─ Coupling to the node bus
─ Organization of the data flow from and to the peripheral elements and communication
interfaces that can be used on the basic system element
─ Freely parameter-settable distribution of the messages
· Operating System - MQX
· Supplementary Module Functions
─ Coupling to the supplementary module bus
─ Freely parameter-settable organization of the data flow from and to the messages on
the supplementary modules
· Ax Bus Driver
Periodical and spontaneous communication with SICAM AK 3, SICAM AK, SICAM TM and
AM 1703 – peripheral elements with IEC functionality over the serial Ax 1703 peripheral
bus (up to 16 peripheral elements)
· Standard Open-/Closed Loop Control Function (PLC)
for automation functions in function diagram technology with CAEx plus.
· Spontaneous Data Forwarding from and to Peripheral Elements
· Synchronizing Function for Command Procedure (DI-DO coupling)
(for pure peripheral modules this control takes place automatically on this firmware)
· Interface for Safety Firmware

DC0-117-2.04, Edition 04.2015
3.9 Safety Communication between BSE and Safety I/O

Modules
For the safety-oriented communication between the basic system element and the safety I/O
modules a Safety Layer is implemented over the standard communication channel. The
standard communication channel thereby serves as transport medium for the safety-oriented
messages.
The Safety Layer
The transmission of the process images and spontaneous information between the basic
system element and the I/O modules takes place over the Ax 1703 peripheral bus and the
TM-Bus. The Ax 1703 peripheral bus provides the communication between the basis system
element and the peripheral coupling modules, while the TM-Bus is responsible for the
communication between the peripheral coupling module and the I/O modules.
The safe communication corresponds with the PROFIsafe – Profile for Safety Technology IEC
61784-3-3 on PROFIBUS DP and PROFINET I/O.

DC0-117-2.04, Edition 04.2015
3.10 Safety Communication between two Safety PLC’s
Process data are exchanged periodically between two Safety PLC’s (safe user programs)
over a secure communication channel. This is realized as a point-to-point connection
according to the Master-Slave principle. The terminals of the point-to-point connection form
“Safety Communication Modules” in the Safety user program, which are configured once as
Master and once as Slave. The Safety PLC´s can be configured in different AU’s as well as in
the same automation unit. The transmission path between the two terminals is defined as
black channel.
Example 1: Safety communication between two SICAM AK 3 or SICAM AK (AU1 +

AU2) and safety communication from AU1 to SICAM TM peripheral
elements
**)
communication element
*) AP-0771/SPLC01
sCM sPLC safety

Node bus
AU2
PLC standard
SL
Safety Layer

Protocol element Protocol element(s)
SL
SL
Processing and
*)
Protocol element communication element Protocol element(s)
Safety Layer
AP-0771/SPLC01 SL
AU1
PLC standard
Node bus
sPLC safety sCM
Safety Layer
**)
Safety Layer
PE-641x DI-6170, DO-6270, AI-6370
TM bus
Ax Peripheral bus
spontaneous data
Peripheral
USIO66 interfacing
further Process
peripheral elements
*) **)

DC0-117-2.04, Edition 04.2015
Example 2: Safety communication between SICAM TM (AU1) and SICAM AK 3 (AU1)

and safety communication from AU1 to SICAM TM peripheral elements
**)
*)
communication element AP-0771/SPLC01
PLC standard sCM sPLC safety

AU2
Node bus
Safety Layer
Protocol element
SL
Protocol element Safety Layer
AP-0771/SPLC01
AU1
PLC standard
sPLC safety sCM
Safety Layer
CP-6014/CPCX65
Safety Layer
PE-641x DI-6170, DO-6270, AI-6370
TM bus
Safety Layer
periodical safety data

Ax Peripheral bus
Peripheral
USIO66 interfacing
spontaneous data
sCM ... safety Communication modul further Process

peripheral elements
*) **)
The secure communication channel is defined by the following characteristic values:
· Configuration:
─ Singular communication channel
─ Redundant communication channel
· Parameterization of the communication module in the user program (CAEx plus):
─ Assignment of the remote station
─ Definition of the timing behavior
─ Assignment of the process data
· Transmission of the process data:
─ Periodical with settable grid
─ Spontaneous controlled by application
─ Multiple communication channels to one remote station
· Transmission protection:
─ Data protection by PROFIsafe
─ Data topicality with Watchdog function
─ Retry handling for communication faults

DC0-117-2.04, Edition 04.2015
· Diagnostic functions and error detection:

─ Behavior with communication errors
─ Behavior with system errors
3.10.1 Configuration of the Communication Channel
3.10.1.1 Singular Communication Channel

A singular “Secure Communication Channel” establishes a point-to-point connection between
2 Safety PLCs. In this case 1 PROFIsafe channel is used, which protects the “Standard
Communication Path”. The number of connections is limited to 127 channels, whereby a
maximum of 126 Master communication channels can be configured.
If the communication connection fails, then the output “State” of those singular communication
modules which represent the communication channel is set to FALSE on expiry of a timeout
(WatchdogTime).
*)
Processing and communication element
SICAM AK 3 or SICAM AK (AU1)
AP-0771/SPLC01
Application program
Communication
module - Master
Sa
fe r
ty aye
L
ty aye
fe r
Sa
Communication
module - Slave
Application program
AP-0771/SPLC01
*)
Processing and communication element
*)
CP-2019/PCCX26 (SICAM AK 3)
CP-2017/PCCX25 (SICAM AK)

DC0-117-2.04, Edition 04.2015
3.10.1.2 Redundant Communication Channel

A redundant “Secure Communication Channel” establishes a point-to-point connection
between 2 redundant Safety PLCs. In this case 2 PROFIsafe channels (redundant
communication module) are used, which protect the “Standard Communication Paths”.
The following diagram shows a possible configuration for a redundant secure communication.
This configuration shows a singular “head end” with 2 redundant substations. However, the
head station can also be operated redundant.
The redundant Safety PLC´s must be parameterized identically. A PROFIsafe connection is

established to both automation units. The “Voter” of the redundant communication module
decides from which of the two communication channels the receive data are forwarded to the
user program. After detection of communication problems in one receive channel, this
communication module Voter accesses the other receive channel and the secure
communication connection continues without failure.
*)
Processing and communcation element
AP-0771/SPLC01
Communication
module - Master
Application program
Saf
r
Sa
ye
r
aye fet
ety
La
yL y La
fet
ty
Lay
ye
Sa r
fe
Sa
r e
Communication Communication
module - Slave module - Slave
Application program Application program
AP-0771/SPLC01 AP-0771/SPLC01
*) *)
Processing and communcation element Processing and communcation element
passive active
Redundancy switchover
*)
CP-2019/PCCX26 (SICAM AK 3)
CP-2017/PCCX25 (SICAM AK)

DC0-117-2.04, Edition 04.2015
The switchover (Voter) takes place according to the following priorities:
· Priority 1:
If one communication path fails, then the process image (PAB) of the other controller is
forwarded to the user program (Top Priority). The failure is detected by the PROFIsafe
Stack.
· Priority 2:
For the Voting the application must assign a priority by means of the parameter
“UserPriority”. E.g.: failure of a Safety I/O-module on one of the redundant Safety PLCs:
the UserPriority flag must be set to FALSE by the user program.
For the fault, that both redundant applications are in state „ACTIVE“ or „PASSIVE“, the
voting is controlled with the parameter „UserPriority“. In all other faults the latest valid
voting-state remains.
Note
The parameter „UserPriority“ must be set per default from the application, otherwise
no distinction is possible between the redundant Aus.
· Priority 3:
If the active communication path fails, then the process image of the passive controller is
forwarded to the application.
However, this concerns only a preferential voting, since the current process data are
always transmitted in both channels. The ACTIVE/PASSIVE identifier of the redundancy
switchover function is transmitted in the “System data” of the safe process data.
· Priority 4:
If both communication paths are invalid or have failed, then the process values and the
output “State” are brought to the safe state.

DC0-117-2.04, Edition 04.2015
3.10.2 Parameter Setting in the User Program (CAEx plus)

The parameter setting of the safe communication connection is carried out by means of the
safe communication modules in the user program (SICAM TOOLBOX II / CAEx plus).
The following diagram shows the layout of the safety communication modules (singular /
redundant) with the possible parameters (module inputs/outputs).
SI_COM_RED_16BOOL_8REAL
Master
State
DestRegNr
DestCompNr RecOS_Stop
SI_COM_16BOOL_8REAL DestBSENr RecOS_Test
RecOS_Run
DestZSENr
Master State
ID
DestRegNr RecOS_Stop
DestRedRegNr
DestCompNr RecOS_Test
RecOS_Run DestRedCompNr
DestBSENr
DestRedBSENr
DestZSENr
ID DestRedZSENr
SendSpontan RecSpontan
SendSpontan RecSpontan
SendCycleTime
SendCycleTime
WatchdogTime
WatchdogTime
RecDataDis
RecDataDis
UserPriority
SendBOOL_00 RecBOOL_00 SendBOOL_00 RecBOOL_00
SendBOOL_10 RecBOOL_10 RecBOOL_10
SendBOOL_10
SendREAL_00 RecREAL_00 SendREAL_00 RecREAL_00

3.10.2.1 Configuration Parameters

3.10.2.1.1 Assignment of the Remote Station
Master
In general each communication channel is defined by one Master module and one Slave
module.
Dest. Address
The unambiguous destination address of the respective communication partner is formed from
· DestRegNr [0 .. 249] (Region number)

· DestCompNr [0 .. 254] (Component number)
· DestBSENr [1 .. 16,20] (BSE number)
· DestZSENr [128 .. 131] (SSE number)

DC0-117-2.04, Edition 04.2015
· ID [0..126] Instance ID of the communication module of the

destination address.
In the case of a redundant communication channel, a second (redundant) destination address
of the communication partner is parameterized
· DestRedRegNr [0 .. 249] (Region number)

· DestRedCompNr [0 .. 254] (Component number)
· DestRedBSENr [1 .. 16,20] (BSE number)
· DestRedZSENr [128 .. 131] (SSE number)
The same ID is used.
In addition a flag for the validity of the process data must be provided by the application for
voting with redundant communication:
In the case of a redundant communication channel, the process data can be marked as high
priority. This information is an input information for the Voter.
UserPriority[SAFEBOOL]: TRUE = Process data are high priority
FALSE = Process data are low priority
3.10.2.1.2 Definition of the Timing Behavior
Watchdog Time
The parameter WatchdogTime defines the upper limit for the time-related monitoring
(Timeout) of the cyclic communication.
Value range: 100 ms – 655 sec (10 min 55 sec)
SendCycleTime
The parameter SendCycleTime defines the periodical grid for sending the system data
container with the process data.
Value range: 50 ms – 300 sec (5 min)
This is only evaluated by the Master, but must be less than the Watchdog time.

DC0-117-2.04, Edition 04.2015
3.10.2.1.3 Change of Parameter Values during Operation
Master + Dest. Address + ID
The configuration parameters “Master” + “Destination Address” + “ID” is the unambiguous

KEY of the communication channel. If one of these configuration parameters is changed by
the user program, then it concerns a new communication channel instance that is configured
new. A corresponding remote station must also be available in the network for this.
Watchdog Time
The Watchdog time is a configuration parameter of the PROFIsafe channel and cannot be
changed during operation. If it is changed despite this, then an internal error is set, that can
only be deleted again with a reset.
SendCycleTime
This configuration parameter is applied during operation and is automatically active after the
next message is sent.
3.10.2.2 Simulation Mode
The parameter RecDataDis is used to deactivate the receive data for simulation purposes
(Online-Test).
This input suppresses the output of the receive data. The output can be simulated via an
Online Test field in the CAEx plus Online Test, which is connected to the respective output of
the communication module.
Caution
The simulation mode “RecDataDis” is only evaluated in the operating state “STOP” and “TEST”.
In the RUN state the outputs are always forwarded.
3.10.2.3 Assignment of the Process Data

The Sendxxx and Recxx inputs/outputs define the process data to be transmitted.
Depending on the type of module, up to

─ n Boolean binary information Type SAFEBOOL
─ o Real measured values Type SAFEREAL
can be transmitted.
Communication module variants:
Name Number Number

SAFEBOOL SAFEREAL
SI_COM_16BOOL_16REAL 16 8
SI_COM_RED_16BOOL_16REAL 16 8
The process data to be transmitted are provided over inputs of the communication module
and transmitted to the remote station by the transmit functions. The process data received by
the remote station are forwarded to the user program over outputs of the communication
module.

DC0-117-2.04, Edition 04.2015
3.10.2.4 Operating State of the Remote Station

In addition to the process data, the operating state of the remote station is communicated
safely and made available to the user program over corresponding outputs
· RecOS_Stop,
· RecOS_Test,
· RecOS_Run.
If safe communication is maintained the output “State” is set to TRUE.
3.10.2.5 Communication Status

The output “State” indicates the connection status of the communication channel.
State = TRUE Communication channel is active, process data are exchanged.

(with redundant configuration at least one communication channel)
State = FALSE Communication channel failed

(with redundant configuration both communication channels)

DC0-117-2.04, Edition 04.2015
3.10.3 Transmission of the Process Data
3.10.3.1 Periodical with Settable Grid

The communication module / Master sends the process data of the Master to the
communication module / Slave in the grid of the “SendCycleTime”. The communication
module / Slave receives the process data, forwards it to the user program and sends its own
process data to the Master as reply. Consequently a periodical exchange of process data
takes place between Master and Slave.
The communication module / Slave does not evaluate the parameter “SendCycleTime”.
3.10.3.2 Spontaneous Controlled by Application

A positive edge of the parameter SendSpontan causes the information to be sent
spontaneously before expiry of the SendCycleTime. The reception of spontaneous information
is signaled by the output parameter RecSpontan. In this case no reply is sent from the remote
station.
e.g. transmission of Emergency Stop information

DC0-117-2.04, Edition 04.2015
3.10.3.3 Timing Behavior

The following diagram shows the chronological sequence of the communication messages
with a singular communication channel.
The transmission of the process data in the periodical grid (Master / Slave message
exchange) as well as the transmission of spontaneous forwarding of process data are shown
(both for Master as well as Slave).
In addition it shows the Retry behavior with a fault and failure of the communication
connection and the behavior of the status outputs (communication ok/nok) of the
communication module.
CycleTime
20ms
MASTER
Zyklus
Anwenderprogramm
SendCycleTime
100ms
Daten senden
(Systemtelegramm)
Daten empfangen
(Systemtelegramm)
WatchdogTime
Watchdog Watchdog Watchdog Watchdog Watchdog 240ms
retrigger retrigger retrigger retrigger retrigger
Kommunikationsmodul
Status Ausgang
Datenleitung STÖRUNG AUSFALL
SLAVE
Zyklus
Anwenderprogramm
Daten empfangen
(Systemtelegramm)
Daten senden
(Systemtelegramm)
Watchdog Watchdog WatchdogTime

Watchdog Watchdog Watchdog
retrigger retrigger 240ms
retrigger retrigger retrigger
Kommunikationsmodul
Status Ausgang
100ms 200ms 300ms 400ms 500ms 600ms 700ms 800ms 900ms

DC0-117-2.04, Edition 04.2015
3.10.4 Transmission Protection
3.10.4.1 Protection by PROFIsafe
The secure communication channel is realized with a system data container which is
protected by the PROFIsafe Stack. Due to the PROFIsafe protection at the source and
destination (Safety SPLC function) the communication connection is defined as “black
channel”, through which the communication path is not safety-relevant. The implemented
protection algorithms of the PROFIsafe Stack are certified according to SIL 3.
For this reason all existing communication protocols (e.g. Fast Ethernet IEEE 802.3 10/100,
serial protocols) can be used. However, it is a question of the protocol bandwidth in which
periodical grid the safe communication channel can be operated.
3.10.4.2 Data Topicality with Watchdog Function

The secure communication connection includes Timeout detection (Watchdog function). On
reception of a system data container, the timer is retriggered for the monitoring of the
Watchdog time (Parameter WatchdogTime). If no further system data container is received in
this time window, then the secure communication connection and the safe state of the process
values is terminated (“State” output = FALSE).
Caution
The parameter WatchdogTime must always be greater than the transmit cycle time “SendCycleTime”,
otherwise a diagnosis is set. A factor of at least 2 is recommended between WatchdogTime and
SendCycleTime.
3.10.4.3 Retry Handling with Communication Faults

To increase the availability of the secure communication connection, Retries are sent for brief
communication failures. The number of retries can be controlled with the parameter
“SendCycleTime” or “WatchdogTime”. If the “WatchdogTime” is greater than the
“SendCycleTime” by a factor of 3 (+ Reserve), then 2 system data containers may be lost.
Caution
The “WatchdogTime” determines the system response time of the safe communication connection.
3.10.4.4 Safe State with Communication Failure

If the connection fails, then the outputs are switched to the safe state:
─ Initial “State” = FALSE

─ Outputs of the operating state
RecOS_Stop = TRUE
RecOS_Test = FALSE
RecOS_Run = FALSE
─ Output “RecSpontan” = FALSE
─ Process data outputs
RecBOOL_xx = FALSE
RecINT_xx = 0
RecREAL_xx = 0

DC0-117-2.04, Edition 04.2015
3.10.5 Diagnostic Function for Error Detection
3.10.5.1 Behavior with System Errors

If a system error occurs, then the Safety Application is switched to the operating state KILL. In
this case, the Safety PLC is no longer processed and consequently no further periodical
process data are also sent. As a result the remote station detects a communication failure.
Type of error Reason / cause of the error Reaction to the error
General system error of the If the Safety Application is System error

Safety Application switched to the operating state Operating state “KILL”
KILL due to another error, then
the Safety Communication is
also automatically no longer
processed.
2 communication modules The key for the identification of System error
parameterized with the same the modules is the Destination Operating state “KILL”
destination address Address + ID.
The unambiguity of the
Destination Address is checked
in every cycle.
Too many communication The number of communication The generation of code is aborted
modules parameterized modules is already checked with a corresponding error
during the CAEx plus code message
generation.
In addition the Safety Communication function is subjected to the standard error detection
mechanisms of the PROFIsafe Stack.

DC0-117-2.04, Edition 04.2015
3.10.5.2 Behavior with Communication Errors

If a parameter error occurs in a communication module, then this communication module is
switched Not Ready and the state output set to FALSE. The output data of the module are
switched to the safe state.
Type of error Reason / cause of the error Reaction to the error
Plausibility check of the Region number, component State output = FALSE

Destination Address. number, BSE number and SSE
number must be within the valid Entry in the diagnostic treatment
range. with plain text diagnosis in the tool.
Error in the parameter The “WatchdogTime” must be State output = FALSE
setting of the parameterized greater than the
“WatchdogTime”. “SendCycleTime”. Entry in the diagnostic treatment
with plain text diagnosis in the tool.
Change of the The change cannot be applied Entry in the diagnostic treatment
“WatchdogTime” during during operation, because it with plain text diagnosis in the tool.
operation concerns a configuration
parameter of the PROFIsafe User must trigger a Reset.
Slave.
Communication modules The source address of the Entry in the diagnostic treatment
are addressed by 2 received message is checked. with plain text diagnosis in the tool.
sources. If the communication module is
also addressed by a false source,
then this message is discarded.
Communication module If the communication module is State output = FALSE
is addressed by a false also addressed by a false source, Entry in the diagnostic treatment
source. then this message is discarded. with plain text diagnosis in the tool.
Type of communication In the Safety communication State output = FALSE
module inconsistent message the type of the
between Master and communication module is also Entry in the diagnostic treatment
Slave. entered. with plain text diagnosis in the tool.
This is verified on reception of the
communication message.

DC0-117-2.04, Edition 04.2015
3.10.6 Requirements on the User Program
The secure communication channel transmits process data between 2 Safety PLC´s. The safe
state of a communication channel is defined by the output “State = FALSE” and “Process data
= 0”. Apart from that, no action is performed by the system, e.g.: deactivation of the local safe
outputs. The user program is responsible for this.
For this reason the following precautions are to be taken in the user program:
· With a failure of the communication channel

If the safe state of the process data does not automatically deactivate the logic for the safe
output, then the status of the State output must also be linked in the logic.
Caution
The assessment of these failures in combination with error detection measures of the
firmware defines the safe state of the total system.
· Operating status “STOP” of the remote station

If the outputs on the remote station are deactivated by the operating status “STOP”, and if
this status also has effects on the local outputs of the Safety PLC, then the operating
status STOP must also be linked in the logic.
· Restart inhibit after going communication failure
The Safety PLC provides an automatic function for the restart protection. See chapter
Automatic with Restart Inhibit.
However, this parameter has no influence on the Safety communication channels. The
restart inhibit for going communication failures must be realized in the user program.
· Transient information during periodical transmission
Brief information transients (e.g. a 20 ms High Signal) are not transmitted during a
periodical transmission (e.g. in a 100ms grid). They are only transmitted by chance, if
precisely the 20ms transient is present at the transmission initiation.
To transmit this binary information an application-related transient handling must be
implemented in the user program.
Safety Communication – User Program Transient Handling

MASTER SLAVE
SI_COM_16BOOL_8REAL SI_COM_16BOOL_8REAL
TRUE Master State FALSE Master State
DestRegNr RecOS_Stop DestRegNr RecOS_Stop

DestCompNr RecOS_Test DestCompNr RecOS_Test
DestBSENr RecOS_Run DestBSENr RecOS_Run
DestZSENr DestZSENr
ID ID
SendSpontan RecSpontan SendSpontan RecSpontan

SendCycleTime SendCycleTime
WatchdogTime WatchdogTime
20 ms RecDataDis RecDataDis
pulse
SIGNAL S
TRUE SendBOOL_00 RecBOOL_00 SendBOOL_00 RecBOOL_00
R

DC0-117-2.04, Edition 04.2015
3.11 Basic System Element CP-2016 for SICAM AK 3
· Master Control Element from SICAM AK 3 (M-CPU)

· Not Safety-relevant
· Central System Functions
· TOOLBOX II Connection
Detailed information about this system element can be found in the following documents:

3.12 Basic System Element CP-2014 for SICAM AK
· Master Control Element from SICAM AK (M-CPU)

· Not Safety-relevant
· Central System Functions
· TOOLBOX II Connection


DC0-117-2.04, Edition 04.2015
3.13 Basic System Element CP-2019/PCCX26 SICAM AK 3
Running on the basic system element CP-2019/PCCX26 are the
· Standard Firmware PCCX26

This firmware contains the standard functions (Standard-PLC, communications function +
local system functions) and is therefore not safety-relevant.
· Safety Firmware AP-0771/SPLC01
This firmware contains all safety-relevant functions (Safety-PLC + Self-test functions).
Both firmwares are independent system elements in the SICAM TOOLBOX II and can be
loaded into the automation unit independently of each other.
The hardware (CP-2019) is not safety-relevant.
Note
If the basic system element CP-2019/PCCX26 is configured with the safety firmware AP-0771/SPLC01,
the associated labeling strips (TC2-066) in the front panel of the housing of the automation unit must be
exchanged for the yellow safety labeling strips.


DC0-117-2.04, Edition 04.2015
3.14 Basic System Element CP-2017/PCCX25 SICAM AK
Running on the basic system element CP-2017/PCCX25 are the
· Standard Firmware PCCX25

Note
If the basic system element CP-2017/PCCX25 is configured with the safety firmware AP-0771/SPLC01,
the associated labeling strips (TC2-066) in the front panel of the housing of the automation unit must be
exchanged for the yellow safety labeling strips.


DC0-117-2.04, Edition 04.2015
3.15 Basic System Element CP-6014/CPCX65 SICAM TM
Running on the basic system element CP-6014/CPCX65 are the
· Standard Firmware CPCX65


SICAM TM System Datasheet MC6-007-2
SICAM TM CP-6014/CPCX65 Datasheet MC6-033-2
Note
If the basic system element CP-6014/CPCX65 is assembled with the safety-firmware AP-0771/SPLC01,
then a SICAM Safety-label (TC6-221 / 6MF13130GC210AA0) must be placed on the housing.
Position see picture:

DC0-117-2.04, Edition 04.2015
3.16 PE-641x/USIO66 Peripheral Coupling Module
· Not safety-relevant
· Standard telecontrol functions
· 1 ms time tagging of standard I/O modules
· 10 ms time tagging of safety I/O modules
· Conversion of the safety-relevant periodical information from Ax-PE-Bus and TM-Bus

PE-641x/USIO66 System Element Datasheet MC6-031-2.04

DC0-117-2.04, Edition 04.2015
3.17 Safety I/O Modules
3.17.1 Introduction
There are 2 types of safety I/O modules available. These are dies:
· Safety Input Modules

These acquire the signal states of safety-oriented sensors and send corresponding
information to the safety application.
· Safety Output Modules
These receive information from the safety application and forward this to the process
peripherals.
DI-6170 Binary input module; 8 digital inputs; 24 VDC signal voltage

DO-6270 Binary output module; 4 digital outputs; 24 VDC signal voltage
AI-6370 Analog input module; 4 analog inputs; 4-20 mA
Detailed information about these modules can be found in the following documents:

SICAM TM 1703 I/O-Modules DC6-040-2 (from Revision 04)
3.17.2 Basic Concept
· The safety I/O modules have a 2-channel structure. Two CPUs are used, which mutually
monitor each other and the surrounding switching elements via crosswise data
comparison and by means of a State-Machine form a “Super-Watchdog”.
· Both CPU’s are monitored by an independent HW-Watchdog. The expiry of one of the two
watchdogs brings both the own as well as the other CPU to the safe state.
· The voltage supply for the CPU’s or their monitoring also takes place 2-channel, so that an
individual malfunction does not lead to the faulty behavior of both CPUs.
· The setting of the addressing on the I/O module (PBA#, IOM#) is used for monitoring the
correct addressing of the module, which is specified by the SICAM RTUs system
architecture.
· There is a galvanic isolation to the TM-Bus, through which decoupling is achieved.
· All galvanic connections (e.g. synchronization) between the two channels are safely
separated by decouple resistors. These decouple resistors are designed so that an error in
one channel (Common Cause) cannot influence the other channel.
· LED displays: System LEDs (Ready, Safety, Error) and Process LEDs
3.17.3 Addressing the Safety I/O Modules
Located on the safety I/O modules are two rotary switches. With these it is set, at which
position of the SICAM RTUs system the respective module is used.
The first rotary switch determines the PBA# (=peripheral module address) and the second
rotary switch determines the IOM# (=position number of the module on the peripheral
element).

DC0-117-2.04, Edition 04.2015
Consequently the safety I/O modules can be unambiguously identified and mistaking is
prevented.
Both numbers are assigned through the configuring in the OPM II and entered in the safety
parameters. On startup and during operation the set addresses are checked for plausibility.
3.17.4 Monitoring the Supply Voltage
The supply voltage on the I/O modules is that voltage from which the sensors / actuators and
the entire module is supplied. When a certain voltage range is undershot or exceeded a
passivating of all channels takes place. If possible a diagnosis is transmitted and a Power
Down initiated with subsequent Power Up.
· Overvoltage 24 VDC
protection against:
─ Destruction of the module
─ Undefined behavior of the sensors or actuators
· Undervoltage 24 VDC
protection against:
· Overvoltage 5 VDC
protection against:
─ Destruction of the module
· Undervoltage 5 VDC
protection against:
3.17.5 DI-6170
The DI-6170 provides 8 inputs for the acquisition of binary states.
The binary information created as binary states are guided to the ADCs over a voltage
distributor and processed further analog. This permits a cross comparison of the measured
binary information voltage and therefore mutual monitoring for observance of the tolerances in
real-time. Excessive deviations indicate a component fault (short circuit, value deviation, ADC-
error).
A parameter-settable cycling of the external signal voltage enables the discovery of diverse
(external) faults.
The safe state of the binary information inputs is defined by the value "0" for the binary
information input and the value "1" for the associated status.
3.17.6 DO-6270
The DO-6270 provides 4 outputs for the activation of external loads.
It is ensured through the monitoring of the sensor voltage, that the external load is activated
with a large enough voltage. The function of the output driver and the external wiring is
monitored by pulses of the output switch.

DC0-117-2.04, Edition 04.2015
The safe state is defined by the termination of the outputs.
Relays with or without electronics can be connected.
3.17.7 AI-6370
The AI-6370 is used for the measurement of four 20 mA currents. The measured values
supplied to the ADC over a voltage distributor are supplied to the CPU via the ADC’s and
checked for plausibility by means of cross-wise comparisons.
The safe state of the measured value inputs is defined by the value "0" for the measured
value input and the value "1" for the associated status.

DC0-117-2.04, Edition 04.2015
4 Safety System Configuration
Contents
4.1 SICAM AK with Electrically and Optically Coupled PE's .................................. 70

4.2 SICAM TM with Electrically and Optically Coupled PE's .................................. 71
4.3 Safety Communication between two SICAM AK.............................................. 72
4.4 Redundant Safety-PLC‘s with singular Periphery ............................................ 73
4.5 Redundant Safety-PLC‘s mit redundant Periphery .......................................... 74

DC0-117-2.04, Edition 04.2015
Safety System Configuration
4.1 SICAM AK 3 with Electrically & Optically Coupled PE's
Ax 1703 peripheral bus

SICAM AK 3 electrical, 16 MBit/s
Patch-cable, up to 3 m length
PS-263x CP-2016 DI-2110 DO -2210 AI-2300 DI-2110 AI-2301 DI-2110 AI-2301 DI-2110 CP-2019 DI-2110 DO -2210 AI-2300 AI-2301 DI-2110 PS-263 x
SICA M AK SI CAM AK
S ICAM
S ICAM
1703
1703
CP-2019
CP-2016 Peripheral element (with standard and safety I/O-modules)
Ax 1703 Peripheral bus

electric, 16 MBit/s
USB-cable Peripheral element (with standard and safety I/O-modules)
up to 3 m length
Peripheral element (with standard I/O-modules)

optic, 16 MBit/s
LWL up to 200 m length
Peripheral element (with standard and safety I/O-modules)

Maximum 16
SICAM TM
peripheral elements

DC0-117-2.04, Edition 04.2015
4.2 SICAM TM with Electrically and Optically Coupled PE's
SICAM TM Ax 1703 peripheral bus

electrical, 16 MBit/s
TM 1703 ACP CP-6014

SICAM
Master Control Element CP-6014
SICAM
SICAM
1703
1703

electric, 16 MBit/s
USB-cable Peripheral element (with standard and safety I/O-modules)
up to 3 m length

optic, 16 MBit/s

Maximum 16
SICAM TM
peripheral elements

DC0-117-2.04, Edition 04.2015
4.3 Safety Communication between two SICAM AK

CP-2017
CP-2014
SICAM AK
Standard
Safety
Layer
communication

electrical, 16 MBit/s
SICAM AK
S ICAM
S ICAM
17 03
17 03
CP-2017
CP-2014 Peripheral element (with standard and safety I/O-modules)

electric, 16 MBit/s
USB-cable
up to 3 m length

optic, 16 MBit/s

Maximum 16
SICAM TM
peripheral elements

DC0-117-2.04, Edition 04.2015
4.4 Redundant Safety-PLC‘s with singular Periphery
SICAM AK 3 (AU1) SICAM AK 3 (AU2)
PS -263x CP- 2016 DI- 2110 DO-2 210 A I-230 0 DI-211 0 DI-2110 DI -2110 CP -2 019 DI- 2110 DO-2210 A I-230 0 DI-211 0 PS -26 3x PS -26 3x CP- 2016 DI -2110 DO- 2210 A I-2 300 DI- 2110 DI-2110 DI-2110 CP-2 019 DI -2110 DO-22 10 A I-23 00 DI-2 110 P S-2 63x
A I-2 301 A I-2301 A I-2301 AI-2 301 A I-230 1 A I-230 1
SICAM AK SIC AM AK SIC AM AK SIC AM AK
CP-2019 CP-2019
CP-2016 CP-2016
Standard Safety
communication Layer
SICAM AK (AU3)
SICAM AK (AU4)
CP-2017 CP-2017
CP-2014 CP-2014
SICAM
1703
Peripheral element
(with standard and safety I/O-modules)
Maximum 16 SICAM TM
peripheral elements
Warning
· The Activ/Passiv – switch must guarantee, that only one component is active. The implementation of
this function is in the users responsibility.
· It is necessary to check via the Safety-monitor, if both Safety-PLC’s have the same state of parameters
and are in state RUN.
See also: Commissioning of redundant Safety-PLC's

DC0-117-2.04, Edition 04.2015
4.5 Redundant Safety-PLC‘s mit redundant Periphery
SICAM AK 3 (AU1) SICAM AK 3 (AU2)
P S-2 63x CP -2016 DI-2110 DO-2210 AI- 2300 DI -2110 DI- 2110 DI-2110 CP- 2019 DI-2110 DO-2 210 AI-2 300 DI- 2110 P S- 263x P S- 263x CP -201 6 DI-2110 DO-2210 AI -2300 DI-2110 DI- 2110 DI-2 11 0 CP -2019 DI-2110 DO-2 210 AI- 2300 DI -2110 P S -263x
AI- 2301 A I-2 301 A I-23 01 A I-2301 AI-2 301 A I-2 301
SICAM AK SICAM AK SICAM AK SICAM AK
CP-2019 CP-2019
CP-2016 CP-2016
Standard Safety
communication Layer
SICAM AK (AU3)
SICAM AK (AU4)
CP-2017 CP-2017
CP-2014 CP-2014
SIC AM
SIC AM
1703
1703
Peripheral element Peripheral element

(with standard and safety I/O-modules) (with standard and safety I/O-modules)
Maximum 16 SICAM TM
peripheral elements
Warning
· The Activ/Passiv – switch must guarantee, that only one component is active. The implementation of
this function is in the users responsibility.
· It is necessary to check via the Safety-monitor, if both Safety-PLC’s have the same state of parameters
and are in state RUN.
See also: Commissioning of redundant Safety-PLC's
· Both components must be ckecked for correct wiring and function.

DC0-117-2.04, Edition 04.2015
5 Workflows for working with SICAM Safety
Contents
5.1 Introduction .................................................................................................... 76

5.2 Workflow for Application Development ............................................................ 77
5.3 Design Plant ................................................................................................... 79
5.4 Install Hardware ............................................................................................. 80
5.5 Engineering .................................................................................................... 81
5.6 Verification of the Application.......................................................................... 86
5.7 Download of the Application to the Controller .................................................. 89
5.8 Online Test of the Application ......................................................................... 91
5.9 Validation of the Application............................................................................ 92
5.10 Release of the Application and Operation Preparation .................................... 94
5.11 Operation ....................................................................................................... 98
5.12 Maintenance................................................................................................. 101
5.13 Workflow for the Software Modifications ....................................................... 105
5.14 Commissioning of redundant Safety-PLC's ................................................... 112

DC0-117-2.04, Edition 04.2015
Workflows for working with SICAM Safety
5.1 Introduction
This chapter describes the basic method of procedure for working with failsafe SICAM RTUs
systems.
The workflow plan for the engineering of the individual system elements and the
commissioning of a plant for the “non-safe” standard operation is presumed as known and is
documented in the manuals of the SICAM RTUs product family.
In the following the work steps necessary for the commissioning of a Safety plant are
sketched out. These range from the definition of the plant parameters and the engineering
through to the commissioning and operation of the plant.
Design plant
Install hardware
Engineering
• HW/FW configuration of automation unit
• Set parameter
• Create application and generate code
• Simulate function chart offline
Verification of the application
Download of the application to the controller
Online-test of the application
Validation of the application
Release of the application and operation preparation
Operation • Restart of the automation unit

• Set plant in operating mode STOP
• Set plant in operating mode TEST
• Set plant in „safe“ operating mode RUN

DC0-117-2.04, Edition 04.2015
5.2 Workflow for Application Development
· Before commissioning an application on an E/E/PE system, this application must be

examined according to the regulations of the underlying standards.
· The development process valid for the application (see section 3.1. for requirements) must
define the scope and the measures to perform during the verification and/or the
validation. The steps "Verification" and "Validation" must be done.
· Make sure that all measures for verification, validation and release are performed for the
same version of the application.
For this purpose, identify the application by using CAEx safety.
· Make sure that you are authenticated correctly during verification, validation and release
and that authorized persons only have access to the workstation.
· Bear in mind when planning the examination measures that errors can be implemented
during step "Engineering” of workflow. The end user as well as the programming system or
the PC environment can be the initiator of such errors. Example: because of systematic
errors in the programming system or data corruptions in the memory or on the hard disk.
The detection rate of the errors found during dynamic test only might not be sufficient
depending on the requirements of the underlying standard and on the required safety
integrity level.
Include reviews in the development process and execute them by using Safety V&V to
increase the detection rate.
· Record the progress during your workflow by appropriate tools, in particular during
verification, validation and release. You must not skip any measures during the steps
and/or even steps themselves.
If the workflow or a step has been interrupted or aborted, the recordings must make it
possible to resume the workflow or step where it has been interrupted or aborted. If this is
not possible, you must re-start the workflow and start with step "Engineering" again.
5.2.1 Identify Application by means of Code Fingerprints
There might be different versions of one application.
Therefore, you must make sure after a download and during the current iteration of the
verification, validation and release that the correct application is running on the controller and
all measures are performed for the same version of the application (version "A").
This is possible by using Safety Monitor (Online) and Safety V&V (Offline) and identifying the
application by means of the following fingerprints:
· Code-Fingerprint for program data

Fingerprint that is produced during the generation (Safety converter) of the user program.
This fingerprint changes with every relevant change of the user program.
· Code-Fingerprint for parameter data

Fingerprint that is produced during the generation (Safety converter) of the 1703 safety
parameters.
This fingerprint changes with change of the 1703 parameters.
e.g. Safety I/O module parameters and parameters of the safety firmware (SPLC01).
· V&V data
Fingerprint of the V&V data (status of validation, verification or release)
If one of these statuses change, its fingerprint also changes.

DC0-117-2.04, Edition 04.2015
Record the displayed values of the code fingerprints (e.g. on review or test protocols) when
performing the respective step of the workflow. Compare the recorded values from the earlier
step with the ones displayed in Safety Monitor or Safety V&V while performing the current
step. See the respective step of the workflow to find out which CAEx safety component must
be used to record the values or which one must be used to compare them.
Warning
In case of all comparisons, check whether the values for the above mentioned code fingerprints are
identical. If the values differ, the steps of the workflow are not done for the same application or the same
version of the application.
Note
Safety V&V displays additional fingerprints for information not being code-relevant. They are not needed to
basically identify the application, but they can be used as a basis for other examinations.
How to start the Safety Monitor?

Öpen the SICAM TOOLBOX II tool „PSRII Parameter-Loader“ and select the menu item P ARAMETER –
SAFETY MONITOR.

DC0-117-2.04, Edition 04.2015
5.3 Design Plant
During the design of the plant a risk assessment is carried out for every safety function. Based
on this a corresponding safety class (SIL/PL) is then defined. The requirements on the
components for the realization of the safety functions (open-/closed loop control function,
sensors, actuators) are derived from these. These decisions influence further activities, such
as hardware design, configuration and programming.
Note
Important for the planning is the functional separation of standard and safety functions.

DC0-117-2.04, Edition 04.2015
5.4 Install Hardware
The installation of the hardware of a safety-oriented SICAM system must take place in
accordance with the guidelines of the following documents. These are:
Document name Item number From

Revision
SICAM AK 3 User Manual DC2-027-2 00
SICAM AK User Manual DC2-017-2 00
SICAM TM Installation DC6-015-2 01
SICAM TM 1703 I/O-Modules DC6-041-2 04
They contain detailed information on the following topics:
· Place of installation and space requirement

· Handling assemblies and modules
· Installation of assemblies and modules
· Setting the addresses for the safety I/O modules
· Configuration information
· Wiring of the process peripherals
· Screening/protective earthing/grounding
· Power supply
Note
The power for the safety plant is to be supplied with SELV-conforming power supply
units/batteries/charging devices.
The individual power circuits/supply circuits are to be protected with fuses. A circuit
breaker 2-pole 10 A (or less) characteristic C is prescribed for each peripheral element.
(Standard Type: Siemens 5SY5 210-7).
· Labeling

DC0-117-2.04, Edition 04.2015
5.5 Engineering
The safety-relevant parts of a plant are configured and parameterized in the OPM II just as
standard parts. All engineering activities, from the system diagnostics through to the online
test, are performed with the SICAM TOOLBOX II.
The open-/closed loop control user programs are created using CAEx plus according to the
standard IEC 61131-3. This applies for safety as well as for standard function diagrams. All
data are stored in the SICAM TOOLBOX II database.
SICAM TOOLBOX II
EM II CAEx safety
(Engineering Manager)
OPM II
Safety Umsetzer
Safety-Parameter
Standard (Parameter + FUP)
Parameter
CAEX plus
Safety Safety V&V
Parameter
Safety Parameter
signed
verified & validated
PSRII
(Configuration- and Service Engine)
Safety Monitor
Data flow
CAEx plus test, Parameter
Diagnostics Loader Read fingerprint
Online test Telegram
simulation
Safety Layer
TM 1703 A CP CP-6 014
SICA M

DC0-117-2.04, Edition 04.2015
Design plant
Engineering
Define plant and automation unit
HW/FW configuration of
automation unit
Set Parameter
Create application and

generate code
Simulate function chart offline
5.5.1 Define Plant and Automation Unit
For the initial creation of a plant the configuration data in the OPM II must be entered in the
SICAM TOOLBOX II. This task is supported by "Wizards". The parameterized configuration
data define the plant topology.
· Customer data
· Plant data
· System- and process technical automation units
5.5.2 HW/FW Configuration of Automation Unit
Before the parameter setting an automation unit must be configured with the required system
elements. The configuration is carried out with the tool "OPM II" via the menu items TOOLS |
SYSTEM TECHNIQUE and TOOLS | LIBRARY OVERVIEW .
· Basic system elements

─ CP-2016/CPCX26 (SICAM AK 3)
─ CP-2019/PCCX26 (SICAM AK 3)
─ CP-2014/CPCX25 (SICAM AK)

DC0-117-2.04, Edition 04.2015
─ CP-2017/PCCX25 (SICAM AK)

─ CP-6014/CPCX65 (SICAM TM)
· Configure safety system element AP-0771/SPLC01 as protocol element on
CP-2019/PCCX26 (SICAM AK 3), CP-2017/PCCX25 (SICAM AK) or CP-6014/CPCX65
(SICAM TM)
─ Define target revision of AP-0771/SPLC01 (mandatory)
─ Define Confirmation ID for AP-0771/SPLC01 (optional)
Note
If a Confirmation-ID is assigned, then the user must ensure the storage of this.
· Configure peripheral elements PE-641X/USIO66 on BSE

─ Configure safety I/O modules on the PE-641X/USIO66 (configuration node “Safety I/O-
Modules“).
· Protocol elements
5.5.3 Set Parameters
The system-technical and process-technical settings of a plant are set in SICAM TOOLBOX II
with the tool "OPM II". Safety- and standard-parameter must be treated equally.
· System-Technical Settings
The parameter setting is carried out in the menu tree, respectively below the selected
basic system element:
─ Common settings
─ Time management
─ Communication protocols
─ Network settings
─ Topology
─ Dataflow filter
─ Periphery
─ Decentralized archiving
─ Redundancy
· Process-Technical Settings
The process-technical settings of the system elements can be opened centrally via the
menu item TOOLS | IMAGES
The parameters for the technological processing of process signals reside in the menu tree
below the link images:
─ Addressing
─ Signal preprocessing
─ Signal postprocessing
5.5.4 Create Application and generate Code
The user program for the open-/closed loop control functions is created in the SICAM
TOOLBOX II with the tool CAEx plus according to IEC 61131-3.

DC0-117-2.04, Edition 04.2015
CAEx plus supports the programming languages "FBS" (function block language, function
diagram) and "AS" (sequential function chart language) according to the standard IEC 61131-
3 (Programmable Logic Controllers Part 3: Programming Languages).
Note
Safety programs can only be created in the Function Block Language (FBS). Use of the sequential
function chart language (AS) is not possible.
The tool CAEx plus provides various editors and standard libraries for the creation of the
open-/closed loop control functions.
Precondition
· The signals of the process technical plant created with the "OPM II" converted. This is
carried out with the tool "OPM II" by selecting the menu TARGET SYSTEM | CAEX PLUS |
TRANSFORM… .
· The distinction between standard and safety signals takes place by means of the suffix
_SAFE. In addition the safety signals are identified by means of an attribute in the signal
list.
Note
The user must not use the suffix _SAFE for his own signal names, as these can easily
be mistaken.
Sequence
· Select Safety Resource of the corresponding safety system element (SPLC01)

· Create type instance, define characteristics of the task (only the cycle time can be
changed).
· Open type instance and draw function diagram by using the safety library and the safety
signals. Periodical data points can only be read in via safety signals. All standard signals
are read into the sPLC spontaneously.
Warning
When creating the application, fulfill the requirements presented by the underlying
standards and/or by the underlying development process and described in the
corresponding documents (e.g. in specifications)..
Stick to the guidelines that SICAM Safety gives for programming (see Guidelines for
programming) and mind the restrictions that the respective target system gives.
· Start the code generation

In the "OPM II" by selecting the safety application in the system technique and calling the
function SAFETY FUNCTIONS | CODE GENERATION from the Popup menu.
or
in CAEx plus for the safety resource the menu item CODE GENERATION.
Warning
Check the messages in the programming system for logi.LINT's final messages
"logi.LINT checks finished with 0 messages (with 0 errors)" and
"Finished successfully.". Both messages must be listed, the second one right
after the first one.
You must fix reported problems and generate code anew until both of logi.LINT's final
messages are listed.
Result
· Status “A” is produced automatically through the code generation.

This corresponds to the current application status and can be subjected to a review with
Safety V&V.

DC0-117-2.04, Edition 04.2015
· The safety parameters are exported with the tool and stored in the Oracle database. All
safety parameters are given a checksum.
5.5.5 Simulate Function Chart Offline
The logic operations of a function diagram can be tested in CAEx plus with the OFFLINE-
SIMULATION.
The offline test is identical for standard and safety function diagrams and is started in
CAEx plus with the function "Offline-Simulation". The following possibilities are available:
· Display and force values

· Test switch input/output messages, input/output process images of the peripheral
elements
· Changing the execution status of the open-/closed-loop control function
· Setting breakpoints
· Real time archive
· Display status information
· Read and write variables
· Oscilloscope

DC0-117-2.04, Edition 04.2015
5.6 Verification of the Application
Engineering
Verification
Verification of the
application
The safety parameters are verified using the "Safety V&V” tool. The user program is thereby
represented again in function diagram technology and the safety parameters displayed.
Precondition
· User has the authorization to "Edit Safety Parameters"

· Scope of the verification measures has been defined
· The hints concerning authentication and entry/access to the workplace have been
observed
· In the planning of the test measures reviews have been provided in order to increase the
level of detection of introduced errors
· Suitable tools are available for logging the progress
· The application has been identified with CAEx safety (see section Identify Application by
means of Code Fingerprints). The values of the code fingerprints displayed in Safety V&V
have been logged for further examination (the subsequent comparisons).
· Ensure before the Verification, that the correct transformation database is used:
Check the release information (time tag of the release and user identification) of the
transformation database used in Safety V&V.
· Reviews, as one of the possible verification measures, must be performed with the help of
Safety V&V (see Review of the Application.).
Sequence
· In the system technique of the OPM II on the safety application for the safety resource
start the menu item "Safety V&V".
· Enter the Confirmation-ID (optional). The verification is protected by the Confirmation-ID.
· The user must now verify and confirm the user program. In addition the safety parameters
must be confirmed.
· After the verification has been completed, record the state for the verification in Safety
V&V:
─ Identify the application for which you want to record the state: Compare the values of
the code fingerprints that are displayed in Safety V&V with the recorded values. The
same values must be found.
─ Check which user identification is displayed in the status bar of Safety V&V. Your
identification must be displayed.
─ Enter the state for verification that is matching the results of the verification and save
this state.

DC0-117-2.04, Edition 04.2015
· After the entry of the status Passed or Failed a test report of the application must be
created.
Note
The user himself is responsible for the archiving of the test report.
5.6.1 Definitions for the State of "Verification"
State Result of the verification

Passed The verification has been completed successfully. Anomalies compromising the
commissioning of the application have not been detected.
The application can be released, if validation has been completed successfully as
well.
Failed The verification has not been completed successfully. Anomalies compromising
the commissioning of the application have been detected.
After step "(Re-)Engineering" to fix errors is concluded, you must perform the
other steps of the workflow as defined in the development process, such as a
delta verification.
Unknown The verification has not started yet or it has not been completed.
The verification must be resumed at the same point where it has been aborted.
No predefined measures of the verification must be skipped.
(empty) The empty state is not entered by the end user but it is automatically entered for
the application after the step "Engineering"” of the workflow. The end user can
change an empty state to one of the 3 above mentioned states.
5.6.2 Review of the Application
Reviews are possible verification measures. They must be performed by using Safety V&V.
· Before the reviews are started: Check the following data in Safety V&V:
─ values of the code fingerprints in Safety V&V (to identify the application): Compare the
displayed values with the recorded ones. The same values must be found.
─ user identification in the status bar of Safety V&V
Your identification must be displayed.
─ Release information (time stamp of release and user identification) of used translation
database
· The reviews must examine logic and parameterization of the application data regarding
correctness, consistency and completeness against the corresponding specification.
· Condition for performing the reviews by using Safety V&V: You must be familiar with how
all elements are displayed in Safety V&V, in particular how the logic elements are
displayed.
· Review the following data by using Safety V&V:
─ instance data
Examine the resource (= folder object with icon ) and all its sub-objects that are
displayed in the explorer of Safety V&V.
─ user-defined POUs and data types
Examine all objects under the folder object Library with objects to be examined that
are displayed in the explorer of Safety V&V. All the POUs must contain a logic
describing the behavior.

DC0-117-2.04, Edition 04.2015
─ parameter data
Examine the parameter sets and/or parameter blocks (= folder objects with icon )
and all its parameter tables that are displayed in the explorer of Safety V&V.
· When user-defined POUs are reviewed, make sure that the execution order is shown
within the POUs.
· If you are using examined objects (= examined user-objects, system blocks, system data
types) within the application, during the reviews you must do the following: Check the
consistency of the examined objects against your specification. This is to make sure that
the correct "examined objects" are being used in the application.
· Observe that the state for the verification must be recorded after verification has been
completed. Take note, that after the verification is concluded the status of the verification
is to be recorded.

DC0-117-2.04, Edition 04.2015
5.7 Download of the Application to the Controller
Download
parameter Download of the application
to the controller
Following transformation and verification all data from the engineering must be loaded into the
automation unit (Flash Card in master control element). However that is only possible when
the automation unit is in the operating state STOP, TEST or KILL.
The interrogation of the operating state takes place before the actual loading operation. If the
automation unit is in the operating state RUN, the loading operation is not started. The user is
informed by means of a Message box, at what point he must first switch to the operating state
STOP or TEST in the OPM II and then restart the loading operation.
Precondition
· User has the authorization “Safety Online Functions".

· The HW configuration corresponds with the configuration in the SICAM TOOLBOX II.
Note
The PBA and I/O module numbers are to be set correctly on all Safety I/O modules with
the rotary switches.
· The safety application and/or the safety parameters have been tested and verified offline.
· Automation unit is in the operating state STOP, TEST or KILL.
Sequence
· Ensure, that you are connected with the correct controller.

· It is checked whether the automation unit is in the operating state STOP, TEST or KILL.
· Start parameter loader, select appropriate BSE and start “Initialize Parameters” or "Load
Parameters”. The standard and the safety parameters are loaded together. A selective
loading of safety or standard parameters is not possible in order to guarantee the
consistency of the parameters.
· Make sure, based on the output binary information, that the download has been
successfully concluded
· After the download: Make sure that the correct application is running on the correct
controller (see section Identify application by means of code fingerprints): Compare the
values of the code fingerprints that are displayed in Safety Monitor with the recorded
values. The same values must be found.
Result
· The safety parameters are now loaded in the BSE and protected against modifications
with a checksum.

DC0-117-2.04, Edition 04.2015
· The parameters on the BSE correspond to application status "B". These can be used for
subsequent Delta tests.
· Following the very first initialization the automation unit is in the operating state STOP.
Caution
Switching off the master control element during a loading operation must definitely be avoided, as the data
on the Flash Card could be destroyed as a result.

DC0-117-2.04, Edition 04.2015
5.8 Online Test of the Application
Online-test
Online-test of the
application
After the very first parameter loading the automation unit is in the operating state STOP. In the
STOP state the safety outputs are in the safe state (passivated). In the TEST state the safety
outputs can be switched. To test the outputs one must switch to the TEST state.
Danger
In this operating state the safety measures are switched off. I.e. the plant is in the non-safe state.
Measures are to be taken (e.g. spatial cordoning off of the danger zone) to prevent the endangering of
persons.
This operating state may only be executed for a limited time and must be terminated after commissioning
at the latest.
The loaded and verified user program is tested using the Toolbox in the destination system
with the help of the online test.
The online test corresponds with a graphical display of the function diagram, in which the
current states of the logic are visualized. i.e. The state of binary information is shown in color
(red = on and blue = off) and analog information can be displayed by means of so-called
online test fields.
Precondition
· The safety parameters are loaded in the BSE.
Sequence
· Switch to the operating state TEST. Optionally the Confirmation-ID must be entered
· In the CAEx plus project management select the corresponding safety resource of the
BSE and start the online test via the context menu.
· Test the function with full online test functionality as in the standard PLC (Forcing …).
· If write access to the user program is to take place during the test procedure (e.g. setting
(forcing) of variables), then for reasons of consistency a reset is to be performed after that.
Result
· The safe user program is to be tested on the plant under environmental conditions.

DC0-117-2.04, Edition 04.2015
5.9 Validation of the Application
Validation
Validation of the
application
Precondition
· User has the authorization to “Edit Safety Parameters”

· The safe user program has been tested on the plant under environmental conditions.
· Scope and measures of the validation have been defined
observed
· In the planning of the test measures reviews have been provided in order to increase the
level of detection of introduced errors
· Ensure based on the following points, whether the correct hardware/software is used:
─ Parameter data in Safety V&V for the identification of the hardware/firmware
─ Version numbers of the CAEx safety components used (based on the system
configuration specified by Siemens)
─ Release information (time tag of the release and user identification) of the
transformation database used in Safety Monitor
─ Values of the code fingerprints in Safety V&V (to ensure, that the correct application is
running on the controller; see section Identify application by means of code
fingerprints): compare the values displayed with the logged values. The values must be
the same.
Sequence
· In the system technique of the OPM II on the safety application or in CAEx plus for the
safety resource, start the menu item "Safety V&V".
· Identify the application for which you want to record the status (see section Identify
application by means of code fingerprints): compare the values of the code fingerprints
displayed in Safety V&V with the logged values. The values must be the same.
· Check which user identification is displayed in the status bar of Safety V&V. It must be
your own identification.
· Enter the status of the validation according to the results of the validation process and
save the status.

DC0-117-2.04, Edition 04.2015
· After the entry of the status Passed or Failed a test report of the application must be
created.
Note
Result
· The safety application is now validated and can be released.
5.9.1 Definitions for the State of "Validation"
State result of the verification

Passed The validation has been completed successfully. Anomalies compromising the
commissioning of the application have not been detected.
The application can be released, if verification has been completed successfully
as well.
Failed The validation has not been completed successfully. Anomalies compromising
the commissioning of the application have been detected.
After step "(Re-)Engineering" to fix errors is concluded, you must perform the
other steps of the workflow as defined in the development process, such as a
delta validation.
Unknown The validation has not started yet or it has not been completed.
The validation must be resumed at the same point where it has been aborted. No
predefined measures of the validation must be skipped.
(empty) The empty state is not entered by the end user but it is automatically entered for
the application after the step "Engineering"” of the workflow. The end user can
change an empty state to one of the 3 above mentioned states.

DC0-117-2.04, Edition 04.2015
5.10 Release of the Application and Operation Preparation
Release
Release of the application
and operation preparation
Operation
5.10.1 Release of the Application
The release of an application is an organizational measure by which the application is

declared ready for the overall installation and commissioning. The state for the release must
be recorded in Safety V&V.
Precondition
· User has the authorization to “Edit Safety Parameters”

observed
· The release is carried out by a suitably authorized person
· It has been ensured based on the following points, that the correct hardware/software is
used:
─ Parameter data in Safety V&V for the identification of the hardware/firmware
─ Version numbers of the CAEx safety components used (based on the system
configuration specified by Siemens)
─ Version number of the transformation database used in Safety Monitor (based on the
system configuration specified by Siemens)
─ Values of the code fingerprints in Safety Monitor (to make sure that the correct
application is running on the controller; see section Identify application by means of
code fingerprints): Compare the displayed values with the recorded ones. The same
values must be found.
Sequence
· In the system technique of the OPM II on the safety application for the safety resource
start the menu item "Safety V&V".
· Identify the application for which you want to record the state (see section Identify
application by means of code fingerprints): Compare the values of the code fingerprints
that are displayed in Safety V&V with the recorded values. The same values must be
found.
· Check which user identification is displayed in the status bar of Safety V&V. Your
· Check which state for validation and which state for verification is displayed. Passed and
an authorized person must be displayed for both.

DC0-117-2.04, Edition 04.2015
· Enter the state Passed for the release and save this state.
· With the help of the multifunction bar command EXPORT TEST REPORT record the value
of the V&V fingerprint displayed in Safety V&V after recording the release status, for
further verification (the subsequent comparison).
Note
The parameters are automatically stored in State “C” for a subsequent Delta test.
· Document the revisions of the used, tested hardware and firmware of the plant
─ Documentation of the firmware used (SPLC01)
This is output during the course of the logging for the V&V fingerprint
─ Documentation of the hardware used (CP-2019, CP-2017 or CP-6014).
Note the serial number.

DC0-117-2.04, Edition 04.2015
─ Documentation of the hardware used (Safety I/O Modules)

Safety module
Serial number
(e.g.: BF1208xxxxxx)
Result
· The safety application is now released for safe operation.
5.10.2 Operation Preparation for the Released Application
Precondition
· Make sure that you are connected to the correct controller.
Sequence
· In the programming system: Start the download to the controller. Then check the
messages to make sure that the download has finished successfully.
· Check the values of the code fingerprints in Safety Monitor (to make sure that the correct
application is running on the controller see section Identify application by means of code
fingerprints): Compare the displayed values with the recorded ones. The same values
must be found.
· Compare the V&V- fingerprint that was recorded after acquisition of the release status in
Safety V&V. The same value must be displayed.
· Check the status of the release and the details recorded for this.
Passed must be entered and a person authorized for the release.
· Check the release information (time tag of the release and user identification) of the
transformation database used in Safety Monitor.
· Activate the operating state "RUN“ for the controller.
· Check in the Safety Monitor which operating state is displayed in the Start register. The
operating state “RUN” must be displayed.
· Create the inspection report in Safety Monitor for the released application that is running
on the controller and in commission.

DC0-117-2.04, Edition 04.2015
· Process the exported inspection report according to your company's guidelines, for
instance sign and file a printout of it.
Result
· The automation unit is now in the safe operating state (RUN).

DC0-117-2.04, Edition 04.2015
5.11 Operation
Operation
Restart of the automation unit
Set plant in operating

mode STOP
Set plant in operating

mode TEST
Set plant in „safe“ operating

mode RUN
5.11.1 Restart of the Automation Unit
This use case considers the startup of an automation unit that has already been successfully
set into operation and run in the state RUN.
Warning
The restart protection for the process is not implemented in the firmware of the system components, rather
is in the scope of responsibility of the application. The application must control the restart of the process
dependent on the process states.
The restart behavior can be set with the parameter safe state at channel error
Precondition
· The user program must be released and run free of errors.
Sequence
The user performs a Reset (on the basic system element) or Power-Up. The system executes
the following steps:
· The self-test after power ON.

· The basic system establishes standard communication to the I/O modules via the
peripheral elements
· The safety layer is initialized and the basic system establishes safe communication to the
I/O modules.

DC0-117-2.04, Edition 04.2015
· When all boundary conditions for safe operation are fulfilled the basic system and the I/O
modules switch to the safe operation (RUN). Otherwise the “safe” state (STOP) is
adopted.
· The loaded user program checks the initial conditions regarding the restart protection of
the process.
Result
5.11.2 Set Plant in Operating Mode STOP
Precondition
· User has the authorization “Safety Online Functions”.

· The plant is in the “safe mode”.
Sequence
· In the OPM II system technique on the safety application call the menu item “Display /
switchover operating state”.
· Enter the Confirmation-ID.
· In the dialog activate the operating state STOP.
Result
· The automation unit is now in the safe operating state (STOP).

· The process values of the safe input modules continue to be updated.
· The process values for the safe output modules are passivated.
5.11.3 Set Plant in Operating Mode TEST
Precondition

· The plant is in the “safe mode”.
Sequence
· In the dialog activate the operating state TEST.
Result
· The automation unit is now in the non-safe operating state (TEST).

· The process values of the safe input modules continue to be updated.
· The process values of the safe output modules are activated.

DC0-117-2.04, Edition 04.2015
Danger
In this operating state the safety measures are deactivated. I.e. the plant is in the non-safe state.
persons.
at the latest.
5.11.4 Set Plant in “safe” Operating Mode RUN
Precondition

· The plant is in STOP or TEST mode.
· The user program must be released.
Sequence
· In the dialog activate the operating state RUN.
Result
· The plant is now in “RUN” mode.

DC0-117-2.04, Edition 04.2015
5.12 Maintenance
Maintenance
Exchange basic system element
Exchange safety I/O module
Exchange SD-card
No maintenance work is required unless reference is made to it in the user manual (e.g. AI-
6370 for the period of the guaranteed safety accuracy)
5.12.1 Exchange Basic System Element
Note
When exchanging basic system elements observe the specifications for the Assembly/Disassembly in the
SICAM AK User Manual.
The exchange of basic system elements is possible during operation without firmware
adaptation.
Precondition
· None, the exchange of a basic system element is possible under voltage
Sequence
· Exchange the basic system element

· Compare the V&V fingerprint that was recorded after acquisition of the release status in
Safety V&V. The same value must be displayed.
· Power-Up of the peripheral element with the new I/O module and PE is ready
automatically.
· Document the revisions of the used, tested hardware of the plant

DC0-117-2.04, Edition 04.2015
─ Documentation of the hardware used (CP-2019, CP-2017 or CP-6014).


DC0-117-2.04, Edition 04.2015
Result
5.12.2 Exchange Safety I/O Modules
Note
When exchanging I/O modules observe the specifications for Assembly/Disassembly in the SICAM TM
Installation Manual.
The exchange of Safety I/O modules is possible without firmware adaptation and SICAM
TOOLBOX II.
Warning
The PE coupling module must be switched de-energized beforehand.
Precondition
· The peripheral element with the defective I/O module is in the de-energized state.
Sequence
· Set the PBA number and the module number on the "new” I/O module.
· Document the revisions of the used, tested hardware and firmware of the plant
─ Documentation of the hardware used (Safety I/O Modules)
Safety module
Serial number
(e.g.: BF1208xxxxxx)
· Power-Up of the peripheral element with the new I/O module and PE is ready
automatically.
Result
5.12.3 Exchange SD Card
Precondition
· New SD Card inserted

· Make sure that you are connected with the correct controller.

DC0-117-2.04, Edition 04.2015
Sequence
· Check in Safety V&V the values of the code fingerprints (to ensure, that the correct
application version in the SICAM TOOLBOX II is available for this plant; see section
Identify application by means of code fingerprints): Compare the values displayed with the
logged values.
Note
Observe, that after loading a released application the plant is immediately in the
operating state RUN.
· Start the download (initialize parameters, load firmware) on the controller with the help of
the SICAM TOOLBOX II and ensure based on the output messages, that the download
has concluded successfully.
· Check in the Safety Monitor the values of the code fingerprints (to ensure, that the correct
application runs on the controller; see section Identify application by means of code
fingerprints): Compare the values displayed with the logged values.
· In the Safety Monitor check the operating state of the plant and initiate the corresponding
measures.
Result
· The automation unit is now in the safe operating state.

DC0-117-2.04, Edition 04.2015
5.13 Workflow for the Software Modifications
When an application is modified and this application has already been commissioned by
means of CAEx safety, this modified application must be examined anew according to the
regulations of the underlying standards.
A development process compatible with "IEC 61508-2 (2010)" must include a change
management process during which a change specification and an effects analysis of the
changes are done before the changes are made.
This excludes the usage of Safety V&V as device to perform the effects analysis on the
changes because the compare mode of Safety V&V can be used well only after the changes
have been made.
5.13.1 Workflow with complete Verification/Validation
A modified application can be examined as described in the workflow for the software
development. All steps of the workflow must be performed fully.
Warning
Observe all instructions and notes given.

DC0-117-2.04, Edition 04.2015
5.13.2 Workflow with Delta Examination
CAEx safety provides the possibility to perform a delta verification and a delta validation of the
modified application in order to restrict the scope of the verification/validation.
During the Delta test one of the states is compared with another.
Code generation in CAEx plus

or with OPM safety function
Version „A“
(latest in TBII
generated or in
safety V&V saved
parameter version
TOOLBOX II
re f
Pa in
wa o
De v
m ad
ra saf
„B atio
m et
fir lo
l ta e r s
et y
nd lid
ty er
v e i on
“
er V&
“ a /va
fe et
rif „A
re V
sa ram
„A n
ica “
lea
n tio
tio an
Pa
io a
se
rs ific
n/ d „
va C
ve ver
lid “
lta
at
io
De
Version „B“ Version „C“

(latest in target (latest in TOOLBOX II
system loades released parameter
parameter version) version)
SICAM RTU TOOLBOX II
Attention
Status "B" can also be created offline by generating the Flashcard. In this case this flashcard must be
present in the destination system at the time of the Delta Verification/Validation. Otherwise the Delta
Verification/Validation is not correct.
Precondition
· condition for restricting the scope of the examination measures is the complete
identification of the functions that are affected directly or indirectly by the modifications.
· You must examine the modified application according to the following criteria during delta
examination:
− Does the modified function behave as expected?

− Do the functions that the modifications have affected indirectly still behave
correctly?
Sequence
· development process valid for the application (see Requirements for the development
process) must define the scope and the measures to perform during the verification and/or
the validation. If the development process allows for a delta examination, there must be
appropriate regulations for delta verification and/or delta validation as well.

DC0-117-2.04, Edition 04.2015
· Make sure that all measures for delta verification, delta validation and release are
performed for the same version of the application. Moreover, make sure that the correct
and archived version of the application is used as reference for the comparison. For this
purpose, identify the version of the application by using CAEx safety (see section Identify
application by means of code fingerprints).
· Make sure that you are authenticated correctly during delta verification, delta validation
and release and that authorized persons only have access to the workstation (see
Authentication measures).
· Bear in mind when planning the examination measures that errors can be implemented
during step "Re-engineering” of workflow. The end user as well as the programming
system or the PC environment can be the initiator of such errors. Example: because of
systematic errors in the programming system or data corruptions in the memory or on the
hard disk
The detection rate of the errors found during dynamic test only might not be sufficient
depending on the requirements of the underlying standard and on the required safety
integrity level.
The delta examination requires reviews by using Safety V&V. Make sure during these
reviews that just the requested modifications have been implemented (see also the above
mentioned criteria during delta examination).
· Record the progress during your workflow by appropriate tools, in particular during delta
verification, delta validation and release. You must not skip any measures during the steps
and/or even steps themselves.
If the workflow or a step has been interrupted or aborted, the recordings must make it
possible to resume the workflow or step where it has been interrupted or aborted. If this is
not possible, you must re-start the workflow and start with step "Re-engineering" again.
5.13.3 Identify Versions of Application by means of Code Fingerprints
There might be different versions of one application.
Therefore, you must make sure after a download and during the current iteration of the delta
verification, delta validation and release that the correct application is running on the controller
and all measures are performed for the same version of the application (version "A").
With CAEx safety that is possible through the identification of the application versions based
on the following fingerprints:
· Code Fingerprint of the program data

Is the fingerprint that is produced during generation (Safety Converter) of the user
program.
This fingerprint changes with each relevant change of the user program.
· Code Fingerprint of the parameter data

Is the fingerprint that is produced during generation (Safety Converter) of the 1703 Safety
Parameters.
This fingerprint changes with a change of the 1703 Parameters.
E.g. Safety I/O Module parameters and Safety Firmware parameters (SPLC01).
· V&V Data
Fingerprint of the V&V data (status of validation, verification or release)
If one of these states changes, this fingerprint also changes.

DC0-117-2.04, Edition 04.2015
In order to see the code fingerprints for version "A" as well as for version "B" or version "C",
Safety V&V must have been started for
· "A" as well as for

· "A" compare with "B" or
· "A" compare with "C"
5.13.3.1 Identify Version "A" of Application
Use the code fingerprints for version "A" to make sure that the correct application is running
on the controller and that it is really the same version of the application:
Record the displayed values of the code fingerprints for version "A" (e.g. on review or test
protocols) when performing the respective step of the workflow. Compare the recorded values
from the earlier step with the ones displayed in Safety V&V or Safety Monitor while performing
the current step. See the respective step of the workflow to find out which CAEx safety
component must be used to record the values or which one must be used to compare them.
Warning
In case of all comparisons for version "A", check whether the values for the above mentioned code
fingerprints are identical. If the values differ, the steps of the workflow are not done for the same
application or the same version of the application.

DC0-117-2.04, Edition 04.2015
5.13.3.2 Identify Version "B" and "C" of Application
Use the code fingerprints for version "B" and/or version "C" to make sure that the correct and
archived version of the application is used as reference for the comparison:
Compare the displayed values of the code fingerprints for version "B" and/or version "C" with
the ones re-corded in the respective inspection reports for the archived version of the
application. See the respective step of the workflow to find out when the values must be
compared.
Warning
In case of the comparisons for version "B" and/or version "C", check whether the values for the above
mentioned code fingerprints are identical with the respectively archived code fingerprints. If the values
differ, the steps of the workflow are not done for the archived version of the application that must be used
as reference for the comparison during the delta verification and the delta validation.
5.13.4 Re-engineering in the Programming System
1. Start the programming system and modify the application in it.
Warning
When modifying the application, fulfill the change specification presented by the
underlying standards and/or by the underlying development process and described in
the corresponding documents (e.g. in change orders or review protocols).
Stick to the guidelines that CAEx safety gives for programming (see Guidelines for
programming) and mind the restrictions that the respective target system gives.
2. In the programming system: Start the code generation for CAEx safety.
Warning
Check the messages in the programming system for logi.LINT's final messages "lo-
gi.LINT checks finished with 0 messages (with 0 errors)" and
"Finished successfully.". Both messages must be listed, the second one right
after the first one.
You must fix reported problems and generate code anew until both of logi.LINT's final
messages are listed.
Note
The automatically created work file version "A" is consistent with the current version of
the application after the modification have been made.
5.13.5 Download of the Application to the Controller
· Activate the operating mode "TEST or STOP" for the controller.

· Before the download: Make sure that you are connected to the correct controller.
· In the programming system: Start the download to the controller. Then check the
messages to make sure that the download has finished successfully.
· After the download: Make sure that the correct application is running on the correct
controller (see section Identify application by means of code fingerprints): Compare the
values of the code fingerprints that are displayed in Safety Monitor with the recorded
values (recorded for version "A"). The same values must be found.

DC0-117-2.04, Edition 04.2015
5.13.6 Delta Examination of the Application
Observe the notes under section Workflow with delta examination regarding the following
items:
· complete identification of the functions that are affected directly or indirectly by the
modifications
· criteria for the examination of the application during the delta validation
· archived application as reference for comparison during the delta examination
· scope/measures of delta validation
· authentication and access to workstation
· when planning the examination measures: including reviews in order to increase the
detection rate of implemented errors
· recording of progress by appropriate tools
Before the delta examination: Check the following items to make sure that the correct
hardware/software is used:
· parameter data in Safety Monitor to identify the hardware/firmware

· version numbers of the used CAEx safety components (based on the system configuration
provided by Siemens)
· version number of used translation database in Safety Monitor
· values of the code fingerprints in Safety Monitor (to make sure that the correct application
is running on the controller; see section Identify application by means of code fingerprints):
Compare the displayed values with the recorded ones (recorded for version "A"). The
same values must be found.
After the validation has been completed, record the state for the validation in Safety V&V:
· Identify the current version of the application for which you want to record the state (see
section Identify application by means of code fingerprints): Compare the values of the
code fingerprints that are displayed for version "A" in Safety V&V with the recorded values
(recorded for version "A"). The same values must be found.
· Check which user identification is displayed in the status bar of Safety V&V. Your
· Enter the state for validation that is matching the results of the delta validation (see
Definitions for the state of "Validation") and save this state.
For a subsequent delta examination after the entry of the status Passed or Failed the test
report must be archived.
Note

DC0-117-2.04, Edition 04.2015
5.13.7 Release of the Application and Operation Preparation
5.13.7.1 Release of the Application
This step of the workflow is analogous to the one during the initial examination (see Release
of the application). Observe for the current iteration:
· When you have to compare the values of the code fingerprints (before the release),
compare the values that are displayed in Safety Monitor with the recorded values
(recorded for version "A").
· When you have to compare the values of the code fingerprints (when recording the state
for release in Safety V&V), compare the values that are displayed in Safety Monitor with
the recorded values (recorded for version "A").
5.13.7.2 Operation Preparation for the released Application
This step of the workflow is analogous to the one during the initial examination (see Operation
preparation for the released application). Observe for the current iteration:
· When you have to compare the values of the code fingerprints (after the download),
compare the values that are displayed in Safety Monitor with the recorded values
(recorded for version "A").

DC0-117-2.04, Edition 04.2015
5.14 Commissioning of redundant Safety-PLC's
Redundant Safety-PLC‘s are independent from each other with identical safety parameter and
application program. They may be located in two separate or in one automation unit.
The safety parameter and the safety application program are created on the „Original“
automation unit and afterwards copied to the „Image“ automation unit. This is done while
maintaining the fingerprint. The copying takes place with function „Copy mirror parameters to
..“ in toolset „OPMII“ of SICAM TOOLBOX II.
SICAM TOOLBOX II
TOOLBOX II
Re vision:
L ice ns e P a k:
OPMII - System technique
Ve rsion 5 | S iem e ns AG
*)
AE1
**)
BSE
AP-0771/SPLC01
Safety-Parameter
Safety-Application Program
AE2
*) copy mirror
parameters
**)
BSE
AP-0771/SPLC01
Safety-Parameter
Safety-Application Program
*) **)
SICAM AK 3 CP-2016/CPCX26 (SICAM AK 3)
SICAM AK CP-2014/CPCX25 (SICAM AK)
This function allows, that the safety parameter and safety application program are identical
loaded and no detailed verification and validation of the safety function in the redundant
automation units is required.
The check, if both redundant automation units are loaded correct , is in the responsibility of
the user and takes place by comparison to identical fingerprints in the redundant automation
unit. The tool „Safety Monitor“ is used for this check.
The loading of the safety parameters remains unchanged.
Hint
The timeout(WatchdogTime) of the communication module, in case of redundant communication
channels, must be larger than the time for the redundancy switchover.
Warning
This is only a parameter copy-function in SICAM TOOLBOX II.
The application program of the target system is not synchronized.

DC0-117-2.04, Edition 04.2015
Sequence
· Parameter setting
─ Both BSE, inclusive the SSEs and PEs, must be configured separate.
─ Set connection parameters separate.
─ On the BSE you must set with parameterRedundancy – Red_Sync Org_img which
BSE is the Original and which is the Image.
─ Further you must parametrize (Region-Nr., Component-Nr., BSE-Nr.) which BSE is the
redundant BSE with the parameter Address of the redundant BSE .
· Process technique
─ The parameter are only set for the original BSE. Placing an image on the PEs of the
"Image"-BSE is blocked by TBII.
─ The 1703 transformer converts only the parameters of the "Original"-BSE.
· CAEx plus
─ The function diagram is only created for the "Original"-BSE. Changes in the function
diagram of the "Image"-BSE are blocked.
· Transfomation andSafety V&V
─ Perform "1703 transform" on the original BSE, if the images were changed.
─ Transform CAEx plus.
─ Create the CAEx plus safety-function diagram and generate the code.
─ Open CAEx Safety V&V for verification, validation and release.
· Load and verify the parameter of the „Original“-BSE
─ Load original parameters.
─ Read out the fingerprint with Safety-Monitor and compare with Safety-V&V Fingerprint.
─ Switch Safety PLC into state RUN.
· Copy the mirror parameters
─ Right-click the "Original"-BSE in OPMII and select „Copy mirror parameters to ..“.
─ Right-click the "Image"-BSE in OPMII and select „Insert mirror parameter“.
─ After successful copying, the Safety-Parameter can be loaded into the "Image"-BSE.
· Load and verify the parameter of the „Image“-BSE
─ Load Safety-Parameter into the "Image"-BSE and compare with Safety V&V with the
"Original"-BSE.
─ Read out the fingerprint with Safety-Monitor and compare with the "Original"-BSE.
─ Switch Safety PLC into state RUN.

DC0-117-2.04, Edition 04.2015

DC0-117-2.04, Edition 04.2015
6 Operating Modes
Contents
6.1 Safe Operation ............................................................................................. 116

6.2 Operating Modes .......................................................................................... 117
6.3 Startup ......................................................................................................... 119
6.4 Setting the Operating State with SICAM TOOLBOX II ................................... 120
6.5 Display of the Operating State ...................................................................... 121
6.6 Status of the Subsystems for each Operating State ...................................... 124
6.7 Permitted Operator Inputs............................................................................. 125
6.8 Operating States of the I/O Modules ............................................................. 126

DC0-117-2.04, Edition 04.2015
Operating Modes
6.1 Safe Operation
The safe operation of a SICAM RTUs system is that operating state in which the safety-
oriented communication by means of safety messages is possible and safety functions are
guaranteed.
In this state all safety functions for error detection and error reaction are activated in the
Safety Modules and the Safety Application.
On a SICAM RTUs this operating state is called RUN.
Basically the setting of the operating states is carried out with the SICAM TOOLBOX II
(Loader, Online Test, OPM II) through explicit operator input.
The operating states are displayed on the I/O module, on the BSE, in the OPM II and in the
online test.
Warning
Following an unwanted disconnection of the SICAM TOOLBOX II connection the plant remains in the state
TEST.

DC0-117-2.04, Edition 04.2015
Operating Modes
6.2 Operating Modes
With regard to the operating states both the total system as well as subsystems consisting of
peripheral elements and the safety application are taken into consideration and can adopt the
operating states STOP, TEST, RUN and KILL.
TOOLBOX II Reset
Reset ter
r ame
Error a d
y-p se
a fet elea
S tr
Res ety-par d)
no
(Saf release
are
et ame
STOP KILL
ter
Parameter load RU (safe
Frimware load N mode)
Online-test (S
afe
ty
ar -par
e r am
TE S
ele e
as ter
T
ed
)
STO
P
ST
OP
TEST RUN
TEST
Parameter load (safety
Frimware load RUN (parameter validated operation)
Online-test and released)
6.2.1 RUN
RUN is the “Safe Mode” of the safety system. In this state the safety functions are executed
and the system is protected against modifications of safety-relevant information and
parameters. All outputs are active.
The operating state RUN is achieved through:
· An explicit operator input in the OPM II tool.

· Startup (Reset, Power up) of a plant that was already in operation.
Preconditions for both cases are, that the safety parameters and safety application are
validated and released.
Warning
Following a startup the operating state RUN is adopted, regardless of the operating state set previously.
For Reset or Power-Up the restart protection of the total system, consisting of SICAM RTUs and the plant,
are in the scope of responsibility of the application.

DC0-117-2.04, Edition 04.2015
Operating Modes
6.2.2 STOP
In this state the outputs are passivated (=safe state) and parameters and firmware can be
loaded and tested in the online test with all functions.
The operating state STOP is achieved through:
· Restart of correctly initialized AU with loaded safety application, which however has not
yet been released.
· Change of operating state using the SICAM TOOLBOX II from the operating state RUN or
TEST.
6.2.3 TEST
Essentially corresponds with the operating state STOP, but the safety outputs are activated. A
release of the application does not need to have taken place.
Danger
In this operating state the safety measures are switched off. I.e. the plant is in the non-safe state.
persons.
at the latest.
The operating state TEST is achieved through:
· An explicit operator input in the OPM II tool.
6.2.4 KILL
This state is adopted following system errors and brings the system to the "safe state", which
does not enable any restart without explicit operator input (e.g. Reset, Power up).
The operating state KILL is achieved through:
· A system error (see chapter: Error Detection and Management).
· Restart of a correctly initialized AU without safety application loaded.
Consequences of the “safe state”:
· The outputs are switched without power/voltage

· No updating of the signals takes place at the inputs
· The safety application does not run
· Parameters and firmware can be reloaded

DC0-117-2.04, Edition 04.2015
Operating Modes
6.3 Startup
The “Startup” is a temporary operating state that is achieved either by means of a “Power up”
or “Reset”.
During a startup the following actions are performed:
· Self-tests
· Address assignment and communication setup with I/O modules.
(communication with I/O modules is not safe)
· The safety parameters and the safety application are checked for completeness,
consistency and plausibility.
· The installed modules are checked against the parameter setting (configuration and HW
switches). Deviating modules assume the operating state KILL.
· The outputs remain deactivated
After a successful startup the system is in the state RUN, if safety application and safety
parameters are present and enabled. If this is not the case, the operating state STOP is
adopted.

DC0-117-2.04, Edition 04.2015
Operating Modes
6.4 Setting the Operating State with SICAM TOOLBOX II
On the destination system the user has no direct possibility to set the operating states. The
user can only change the individual operating states (with the exception of KILL) via the
SICAM TOOLBOX II in the OPM II. In addition the input of the Confirmation-ID is required.
The dialog is called from the context menu of the safety application in the system technique.

DC0-117-2.04, Edition 04.2015
Operating Modes
6.5 Display of the Operating State
6.5.1 SICAM AK 3
The display takes place by means of LEDs on every safety I/O module and on the basic
system element. In addition the operating state can be displayed in the SICAM TOOLBOX II
and on any optional control system (standard diagnostic function).
CP-2019
PS-263x CP-2016 CP-2019 DI-2110 DI-2110 DI-2110 DI-2110 DO-2210 AI-2301 AI-2300 AI-2300 CP-201 9 DI-2110 DI-2110 DI-2110 DO-2210 AI-2301 PS-263 x
SICAM AK SICAM AK
The following LED states are assumed in the individual operating states:
Element LED RUN STOP TEST KILL Startup

BSE Ready (RY) lit lit lit dark dark
Error (ER) dark dark dark lit lit
HALT (HLT) dark dark dark flashing dark
Safety (SF) lit dark flashing dark dark
sPLC Run (TSK SF) lit/dark *) lit lit dark dark
I/O-Module Ready (RY) lit lit lit dark dark
Error (ER) dark dark dark flashing lit
*) lit during the processing of the safety application

DC0-117-2.04, Edition 04.2015
Operating Modes
6.5.2 SICAM AK
The display takes place by means of LEDs on every safety I/O module and on the basic
system element. In addition the operating state can be displayed in the SICAM TOOLBOX II
and on any optional control system (standard diagnostic function).

BSE Ready (RY) lit lit lit dark dark
Error (ER) dark dark dark lit lit
HALT (HLT) dark dark dark flashing dark
sPLC Run (TSK SF) lit/dark *) lit lit dark dark
I/O-Module Ready (RY) lit lit lit dark dark
*) lit during the processing of the safety application

DC0-117-2.04, Edition 04.2015
Operating Modes
6.5.3 SICAM TM
The display takes place by means of LEDs on every safety I/O module. In addition the
operating state can be displayed in the SICAM TOOLBOX II and on any optional control
system (standard diagnostic function).
Note
SICAM TM has no display of the operating state on the master control element.
CP-6014
RES
LOC
TM 1703 ACP CP-6014
RY
S I0
S I1
S I2
S I3
CPY
ERx RX TX
/ LK
/ LK
X1
COM
LOC
/P K
/P K
RY
SI0
SI1
SI2
SI3
ER
R ELE ASE
PU SH TO
CPY
ERx RX TX
/LK
/LK
SICAM
COM
/PK
/PK
X15
X16
ER
X14
X5
X10
X11
X12
X3
X6
X7
X8
X9
FB X4
WD
ER
SIM0
TB
SI1 (ETO)
1 2 3 4 5 6
R ELEASE
PUSH TO
M-PRE/0
M-PRE/1
M-PRE/2
M-PRE/3
SI2 (FB)
PUSH TO UNLOCK
SI0
SI3
NC
24-60VDC
X2
X13
PWR

CP-6014 Ready (RY) lit lit lit dark dark
I/O-Modul Ready (RY) lit lit lit dark dark

DC0-117-2.04, Edition 04.2015
Operating Modes
6.6 Status of the Subsystems for each Operating State
The following table shows which functions are possible in which operating state:
Subsystem RUN STOP TEST KILL

Safety Input (Safety DI, AI) activated activated activated passivated
Safety Output (Safety DO) activated passivated activated passivated
Safety Application active active active inactive
Safety Application, Monitoring active active active inactive
Safety Communication from/to I/O Module active active active inactive
Legend:
active ........ The program processing is running
inactive ..... The program processing is stopped
The process values for outputs a re no longer transmitted over the Safety Layer
activated ... Inputs forward the current process values to the safety application
Outputs output the process values determined by the Safety PLC
passivated Process values ‘0’, status “invalid”
Outputs are terminated
Danger
Since in the Online test with write accesses (e.g. forcing) due to the system the Safety PLC program
monitoring would determine a deviation, in this case the program monitoring is deactivated and therefore
false values can be output.
Note
The operating states RUN, STOP, TEST are adopted by all elements involved in the safety function. The
state KILL can also be adopted by individual elements (e.g. I/O module).

DC0-117-2.04, Edition 04.2015
Operating Modes
6.7 Permitted Operator Inputs
The following table shows which operator inputs are possible in which operating state.
Operator Input STOP TEST RUN KILL

Parameter loading of the BSE active active inactive active
Parameter loading M-CPU, other BSE active active active active
Firmware loading of the BSE and its SSE´s active active inactive active
Firmware loading M-CPU, other BSE active active active active
Data flow test Standard Firmware active active active active
Message simulation Standard Firmware active active active active
Revision inquiry active active active active
Diagnostics active active active active
Remote maintenance active active active inactive
Online test Standard Application read / write read / write read / write inactive
Online test Safety Application read / write read / write read inactive
Safety Monitor – Safety Application read read read inactive
ST-Emulation read / write read / write read read / write
Note
If write accesses have been performed in the Online test (e.g. modify variables) on the safety application,
a reset is tripped after switching to the operating state RUN.

DC0-117-2.04, Edition 04.2015
Operating Modes
6.8 Operating States of the I/O Modules
The operating states on the I/O modules are defined according to the operating states on the
BSE. As master the BSE specifies the actual operating states, which are synchronized on the
I/O modules via the safe communication. The state “Startup" is a temporary operating state,
which is necessary for the implementation of the synchronization procedure with the BSE.

DC0-117-2.04, Edition 04.2015
7 Error Detection and Management
Contents
7.1 Introduction .................................................................................................. 128

7.2 Error Classes ............................................................................................... 129
7.3 System Errors .............................................................................................. 130
7.4 Channel Errors ............................................................................................. 132
7.5 Diagnostics................................................................................................... 137
7.6 Measures of CAEx Safety for Fault Avoidance and/or Detection ................... 138

DC0-117-2.04, Edition 04.2015
Error Detection and Management
7.1 Introduction
To achieve functional safety of a machine or plant, it is not only necessary that the safety-
critical parts of the protection and control equipment function correctly, but in the event of an
error also behave so that the plant is brought to a safe state or remains in a safe state. In
addition to the corresponding safety-oriented behavior of the system, an appropriate
diagnostic information is also set.
For this purpose the system continuously checks the correct function of
· the hardware and firmware,

· the communication between the safety application and the I/O modules
· the connected sensors and actuators (as far as possible),
· the safety application

DC0-117-2.04, Edition 04.2015
7.2 Error Classes
Depending on the severity of the error and the system parts affected, error classes are
differentiated:
Error Class Causes Effects

System error · Access violations · Operating state KILL
· Module errors · Safe state
· Communication errors (CRC, · No further check for error going
consecutive number, timing) · Restart only possible via operator input
· Inconsistent parameters
Channel error · Individual input channel errors such · Safe state of the channel affected
as short circuit · Communication with I/O modules continues
· External sensor defective (as far as possible)
· Wiring error · Running check of error going
· Corresponding parameter not · Individual channels are “passivated” the error
plausible reaction is within the scope of responsibility of
· Global Error in user program the application
· Automatic error rectification possible
· Restart possible optionally automatic or by
application
Parameter · Application program not enabled · Operating state STOP
· Safe state

DC0-117-2.04, Edition 04.2015
7.3 System Errors
System errors are errors which bring the total system or parts of the system to the operating
state KILL. Depending on the location of the occurrence (basic system element or I/O module)
there are different effects on the total system.
Possible causes
· Defect of the hardware used (e.g. CPU error, memory error)

· Faulty behavior of the standard and safety firmware
· Faulty behavior of the safety application program
· Faulty behavior of the standard and safety firmware or application program with endless
loops, excessive software run times etc.
· Failure of the 10ms operating system clock
· Irregular (nor equidistant, none, too frequent, too little) processing
· Incomplete processing
· Errors in the communication between basic system elements and I/O modules
Effects
· The system element(s) is/are switched to the safe state.

· According to the part affected the system element (basic system element or I/O module) is
set to the operating state KILL.
· System errors in the basic system element also bring the associated I/O modules to the
operating state KILL.
· Display of the operating state on the LED´s of the system elements (see Display of the
Operating State).
· Dependent on the location of the error there are different effects on the total system
─ System Errors on the Basic System Element
─ System Errors on the I/O Modules with Inputs
─ System Errors on the I/O Modules with Outputs
Remedy
· Diagnosis with the SICAM TOOLBOX II

· Rectify error
e.g. exchange module
· Perform restart
7.3.1 System Errors on the Basic System Element
If a system error is detected on the basic system element, the system element is set to the
operating state KILL. In this operating state the communication to the I/O modules is stopped.
This leads to all I/O modules also being set to the operating state KILL. For output I/O
modules that causes the outputs to be switched off.
A restart takes place by means of a reset or by switching on the supply voltage.

DC0-117-2.04, Edition 04.2015
Danger
If no restart procedure is programmed in the application program, a restart takes place after reset or by
switching the supply voltage on without any further operator input.
7.3.2 System Errors on the I/O Modules with Inputs
If a system error is detected on an I/O module with inputs, the system element is set to the
operating state KILL. In this operating state the communication to the higher level basic
system element is stopped. This leads to all data points of the affected I/O module being set
to the safe state (see Passivating of Channels)
Danger
If the state of the affected data points is not taken into account in the application program, it can lead to
faulty behavior of the plant.
A restart takes place by means of a Reset of the higher-level peripheral element coupling
module (Service Function Online in the TOOLBOXII) or through Power up.
Danger
If no restart procedure is programmed in the application program, a restart takes place after unplugging
and plugging or through exchange of the I/O module without any further operator input.
7.3.3 System Errors on the I/O Modules with Outputs
If a system error is detected on an I/O module with outputs, the system element is set to the
operating state KILL. In this operating state all outputs are switched off. This state is provided
to the application program by the higher-level basic system element. In addition all data points
of the affected I/O module are set to the safe state (see Passivating of Channels)
Danger
In the application program this state is to be taken into account, so that no danger develops for the total
system.
A restart takes place by means of a Reset of the higher-level peripheral element coupling
module (Service Function Online in the TOOLBOXII) or through Power up.
Danger
If no restart procedure is programmed in the safety application, an immediate restart takes place when all
channel errors have been rectified (e.g. after unplugging and plugging or through exchange of the I/O
module) without any further operator input.

DC0-117-2.04, Edition 04.2015
7.4 Channel Errors
Channel errors are errors for which individual data points are set to the safe state
(passivation). Depending on the location of the occurrence (basic system element or I/O
module) there are different effects on the total system.
Possible causes
· Defect of the hardware used (e.g. ADC defect, short circuit in the input circuit)
· Wiring errors
· Sensor defect
· Implausible values of individual data points
· Calculation errors in the application program (e.g. value overflow)
Effects
· Passivation of the affected data point
· Dependent on the location of the error there are different effects on the total system
─ Channel Errors on the Basic System Element
─ Channel Errors on the I/O Modules with Inputs
─ Channel Errors on the I/O Modules with Outputs
Remedy
· Diagnosis with the SICAM TOOLBOX II
· Error rectification (depassivation of channels)
e.g. repair wiring error
· Perform restart.
7.4.1 Channel Errors on the Basic System Element
Errors which occur during the processing of the safety application (global error of a safety
module), lead to a passivating of the safe outputs on the output modules.
Under which conditions a global error is detected can be taken from the Online Help for “CAEx
plus Modules”.
7.4.2 Channel Errors on the I/O Modules with Inputs
If a channel error is detected on an I/O module with inputs, the affected input is set to the safe
state (passivated). The channel error is provided to the safety application. Any further
processing of this information is carried out according to the parameter safe state at
channel error (see Behavior with Channel Errors)
7.4.3 Channel Errors on the I/O Modules with Outputs
If a channel error is detected on an I/O module with outputs, the affected output is set to the
safe state (passivated). The channel error is provided to the safety application. Any further
processing of this information is carried out according to the parameter safe state at
channel error (see Behavior with Channel Errors)

DC0-117-2.04, Edition 04.2015
7.4.4 Behavior with Channel Errors
Warning
The restart protection for the process is not implemented in the firmware of the system components, rather
is in the scope of responsibility of the application. The application must control the restart of the process
dependent on the process states.
The restart behavior for channel errors that are detected by the system can be set with the parameter
safe state at channel error.
Depending on the application, a behavior for the safe state of the automation unit can be
selected.
· User program
The safe state must be ensured through logic links in the safety application.
I.e. the safety outputs must be linked with error conditions in the safety application.
If the “Global Error” is set by the safety application, the safe outputs are also switched to
the safe state in this case.
· Automatic without restart inhibit
As soon as a channel error occurs (e.g. input of the DI_00 is disturbed or a calculation
error in the safety application), all outputs are switched to the safe state. With going fault
the outputs are immediately switched through again.
Note
This confiugration is not permissible for railway applications.
·
· Automatic with restart inhibit
As soon as a channel error occurs (e.g. input of the DI_00 is disturbed or a calculation
error in the safety application is set), all safe outputs are switched to the safe state. With
going fault the switching through of the outputs must be acknowledged via the system
module TB_RESTART_INHIBIT.

DC0-117-2.04, Edition 04.2015
7.4.4.1 User Program
If the parameter safe state at channel error is set to “User Program”, with the
channel error not all outputs of the automation unit are automatically set to the safe state. It
must be ensured through applicative measures, that the corresponding outputs are brought to
the safe state.
Note
Evaluations of the channel errors must be performed in the user program
The applicative measure is only required for channel errors of I/O modules. Channel errors
which originate from the safety application (“Global Error”) automatically set all outputs to the
safe state.
Danger
Binary information output IOM

SI IOMx IN D00 SAFE
IOMx OUT D00 SAFE 2
>=1 & &
SI IOMx IN D00 faulty SAFE
IOM
0
SI IOMx IN D01 SAFE
Current IOMx - IN V00 SAFE

ENO Binary information output IOM
IOMy OUT D00 SAFE 3
SI_ADD SI_LT & &
Current IOMx - IN V00 faulty SAFE
Current IOMx - IN V00 OV SAFE 20000

IOM
1
Current IOMx - IN V01 OV SAFE
>=1
IOM BI output IOMx - OUT D00 faulty SAFE
2
IOM
BI output IOMy - OUT D00 faulty SAFE
Anwenderprogramm
3
GlobalError
Sicherer Zustand bei Kanalfehler =

SI IOMx IN D00 SAFE „Anwenderprogramm“
IOM
4 SI IOMx IN D00 faulty SAFE
Legende:
IOM 0 … DI-6170
IOM 1 … AI-6370
IOM 2 … DO-6270
IOM 3 … DO-6270
IOM 4 … DI-6170 Safety Firmware

DC0-117-2.04, Edition 04.2015
7.4.4.2 Automatic without Restart Inhibit
If the parameter safe state at channel error is set to “Automatic without restart
inhibit”, with a channel error all outputs of the automation unit are automatically set to the safe
state.
Danger

SI IOMx IN D00 SAFE
IOMx OUT D00 SAFE 2
>=1 &
IOM
0
SI IOMx IN D01 SAFE

IOMy OUT D00 SAFE 3
SI_ADD SI_LT &

IOM
1

2
IOM
Anwenderprogramm
3
GlobalError
Sicherer Zustand bei Kanalfehler =

SI IOMx IN D00 SAFE „automatisch ohne Wiederanlaufsperre“
IOM
Legende:
IOM 0 … DI-6170 >=1

IOM 1 … AI-6370
IOM 2 … DO-6270
IOM 3 … DO-6270
Note
This confiugration is not permissible for railway applications.

DC0-117-2.04, Edition 04.2015
7.4.4.3 Automatic with Restart Inhibit
If the parameter safe state at channel error is set to “Automatic with restart inhibit”,
with a channel error all outputs of the automation unit are automatically set to the safe state.
When all channel errors have been rectified (e.g. after unplugging and plugging or through
exchange of the I/O module) a restart first takes place when an explicit operator input (a
positive edge) is detected on the system module for the restart “TB_RESTART_INHIBIT”.

SI IOMx IN D00 SAFE
IOMx OUT D00 SAFE 2
>=1 &
IOM
0
SI IOMx IN D01 SAFE

IOMy OUT D00 SAFE 3
SI_ADD SI_LT &

IOM
1

TB_RESTART_INHIBIT

2
IOM
Anwenderprogramm
3
GlobalError
SI IOMx IN D00 SAFE Sicherer Zustand bei Kanalfehler =

IOM „automatisch mit Wiederanlaufsperre“
S
Legende: RS
IOM 0 … DI-6170 >=1

IOM 1 … AI-6370
IOM 2 … DO-6270
IOM 3 … DO-6270

DC0-117-2.04, Edition 04.2015
7.5 Diagnostics
For the diagnostics of system or channel errors, depending on the detailing required the
following diagnostic possibilities are provided.
· Standard diagnostics
· LED display
7.5.1 Standard Diagnostics
The SICAM TOOLBOX II has the means for diagnostic evaluation and acknowledgement of
the diagnostic information originating from the I/O modules and the basic system element.
In addition, with the standard diagnostics the diagnostic information can be distributed for
further processing (as process information).
Attention
Information of the standard diagnostics must not be used to influence the safe state.
7.5.2 LED Display
Basically the operating states and diagnostic information are displayed on the LED’s of the
automation unit.
· Diagnostic LED’s on the BSE:

Errors of all error classes are indicated via these LED’s.
· Halt LED on the BSE:
This LED is used to indicate the KILL state.
· Error LED on the I/O modules:
This LED is used to indicate the KILL state.
· Safety LED:
Is used to indicate the “safe” operating mode both on the BSE as well as on the I/O
modules.
· Channel LED:
On the I/O modules the current channel state is indicated by the associated channel LED
according to the signal present or output.
In the KILL state or with channel-selective passivation the last state of the channel is
indicated.
The channel LED for non-activated channels remains dark, no status display of any kind
occurs.

DC0-117-2.04, Edition 04.2015
7.6 Measures of CAEx Safety for Fault Avoidance and/or

Detection
· The data is processed by CAEx safety components that are independent of the
programming system.
· Checksums and fingerprints guarantee the integrity of the application data while the data
is processed by CAEx safety until its execution on the controller.
· If the data is corrupted and errors are generated during the processing of the data, the
next processing step will be aborted.
· Code fingerprints are available so that the end user can identify the application data in
CAEx safety.
· The end user must check these code fingerprints after each download, for each validation,
verification and release in order to ensure that the correct application is loaded and
modified.
· CAEx safety executes plausibility checks for the processed data once again before the
data is downloaded (e.g. comparing the checksum of the binary file).
· You can record the result of the examination measures (validation, verification, release) in
component "Safety V&V". The examination measures must be predefined in your
development process. The recorded result of the examination measures is stored in the
application data (including user identification of the person who recorded the result,
date/time and entered comment).
· The application data is displayed within the application "Safety V&V" that is independent of
the programming system so that the data can be reviewed in it: The data is displayed in a
form similar to the programming system.
· Safety V&V displays modifications (enhancements or bug fixes) for an application which
has already been commissioned by means of CAEx safety. This makes a delta verification
and delta validation possible.
· The component "Safety Monitor" enables the examination of the application data on the
controller and of the E/E/PE system itself:
─ identification of the running application by means of code fingerprints
─ state for validation, verification and release of the running application
─ operating state of E/E/PE system
─ other parameter data to monitor the application and/or the E/E/PE system
· Inspection reports about the application (in format "XML" or "PDF") can be generated in
Safety V&V and Safety Monitor. The base for these inspection reports is the application
data process by CAEx safety. Accidental corruptions of the application data are
documented in the inspection report. Moreover, accidental corruptions of the XML
inspection report can be recognized.
· On the controller there is another check making sure that the data can be processed
according to the restrictions of the controller.
7.6.1 Authentication Measures
CAEx safety automatically uses the user identification, when the result of the examination
measures (validation, verification, release) is recorded in Safety V&V.
The user identification of the person is used under which he/she logged on.
Warning
Only authorized persons may have access to the workstations used during verification, validation, release
and for download.

DC0-117-2.04, Edition 04.2015
Appropriate measures must be adopted for unattended workstations (during interrupts, breaks etc.).
Make sure that all persons using the workstation are authenticated correctly.
Note
Example for restricted access:
Apply the operating system features "Locking the computer" and "Screen saver password" when leaving
the workstation unattended. Disclose the required password to authorized persons only.
Safety V&V and Safety Monitor allow to check under which user identification the modifications will be
made resp. have been made. The workflows instruct to check this user identification.
When the examination measures are recorded in Safety V&V, CAEx safety also uses the date
and the time as specified in the operating system.
Note
Change the settings for date/time of the operating system only, if it is imperative to do so (e.g. adjustment
to daylight saving time). Subsequently, the changed timestamp is used in Safety V&V, when the
examination measures are recorded.

DC0-117-2.04, Edition 04.2015

DC0-117-2.04, Edition 04.2015
8 System Response Time
Contents
8.1 General ........................................................................................................ 142

DC0-117-2.04, Edition 04.2015
System Response Time
8.1 General
The shutdown of a plant or machine must occur within a defined time. This time is called
system response time.
The system response time is that time measured between the change of input signal (sensor
DI-6170 or AI-6370) and the output of the tripping signal (actuator DO-6270).
The detection of a safety-relevant error in the system must cause the system to be brought to
a safe state within this time and be kept in it.
The system response time is dependent on the configuration. A distinction is made between
the following configurations:
· Input and Output within a Basic System Element

· Input and Output via Distributed Basic System Elements / Automation Units
8.1.1 Input and Output within a Basic System Element
The maximum achievable system response time (from the change of input signal until output
of the tripping signal) is 100 ms.
The system response time is dependent on the settable cycle time of the sPLC.
The following times must be analyzed for the consideration of the system response time:
(TERF + TBUS + TSPLC x 2 + TBUS + TDO ) < TSYS
TERF ... 10 ms; time for the acquisition on the DI-6170 or AI-6370
TBUS ... 20 ms; time for the processing of the bus transmission
TSPLC . time for the processing of the safety open-/closed loop control function
TDO .... 10 ms; time for the output on theDO-6270
Note
The minimum cycle time TSPLC for the processing is dependent on the number of
processing blocks.
TBUS is comprised of the regular duration for the processing of the communication and the
number of tolerable transmission errors (Retries).
8.1.2 Input and Output via Distributed Basic System Elements /

Automation Units
The maximum achievable system response time (from the change of input signal until output
of the tripping signal) is dependent on the bandwidth of the communication between the
automation units and on the settable cycle times of the two sPLCs.

DC0-117-2.04, Edition 04.2015
Technical Data
The following times must be analyzed for the consideration of the system response time:
(TERF + TBUS + TSPLCM + TWD + TSPLCS + TBUS + TDO ) < TSYS
TERF ......... 10 ms; time for the acquisition on the DI-6170 or AI-6370
TBUS ..... 20 ms; time for the processing of the communication
TSPLCM .. parameter-settable cycle time for the safety open-/closed loop control function
in the master basic system element
TWD .......... parameter-settable watchdog time for the secure communication between basic
system elements / automation units
TSPLCS .. parameter-settable cycle time for the safety open-/closed loop control function
in the slave basic system element
TDO ...... 10 ms; time for the output on the DO-6270
The minimum cycle time TSPLCM and TSPLCS for the processing is dependent on the number of
processing blocks.
TBUS is comprised of the standard duration for the processing of the communication and the
number of tolerated transmission errors (Retries).
The parameter-settable watchdog time for the secure communication between basic system
elements / automation units is calculated from:
TWD > TCYC * (F + 2)
TCYC ..... parameter-settable transmit cycle time for the secure communication between
basic system elements / automation units
F.......... Factor for the maximum permitted number of retries of the communication
channel between basic system elements / automation units
0 = No Retries
The parameter-settable transmit cycle time for the secure communication between basic
system elements / automation units is calculated from:
TCYC > 2 * TCOM + MAX(TSPLCM, TSPLCS)
TCOM .... Transmission time of the message on the transmission link between basic
system elements / automation units
MAX(TSPLCM, TSPLCS)
The greater cycle time for the safety open-/closed loop control function of
master or slave basic system element is to be selected.
TCOM is dependent on the protocol, the type of traffic (point/point, Master/Slave, etc), the
bandwidth and the availability of the communication connection and is comprised of the
standard duration for the processing of the communication without retries.

DC0-117-2.04, Edition 04.2015
System Response Time

DC0-117-2.04, Edition 04.2015
9 Safety Parameters
Contents
9.1 Safety SICAM RTUs Parameters .................................................................. 146

9.2 Safety PLC Parameters ................................................................................ 150
9.3 Standard SICAM RTUs Parameters.............................................................. 151

DC0-117-2.04, Edition 04.2015
Safety Parameter
9.1 Safety SICAM RTUs Parameters
Note
To get to valid parameters the safety code generation and the 1703 converter must be activated.
9.1.1 Configuration and Consistency Parameters of the Safety

Application
The consistency check controls whether the verified, and if applicable also released safety
parameters match the parameters of the standard firmware.
The following are checked:
· the system element name

· the system-technical plant ID
· the region number
· the component number
· the BSE number
· the SSE number
· Firmware name of the safety application
· Firmware revision of the safety application
· Prepared identifier
9.1.2 Configuration Parameters of the Safety Application
The configuration of the safety I/O modules is also contained in the safety parameters. The
PROFISafe Master (Safety-Layer) is configured based on this configuration.
In addition the configuration of the safety I/O modules is checked against the standard
configuration. E.g. if it concerns a USIO66 on which the safety I/O module is configured.

DC0-117-2.04, Edition 04.2015
Safety Parameter
9.1.3 DI-6170
9.1.3.1 Parameter: Test_Cycling_Group_SAFE
The test cycling is used to check the circuitry and the external wiring.
Note
A test cycling is only meaningful when using switches without own power supply and without own testing.
Parameter Value Description

Test_pulse_group_SAFE enabled Test cycling is enabled
disabled Test cycling is disabled

DC0-117-2.04, Edition 04.2015
Safety Parameter
9.1.4 DO-6270
9.1.4.1 Parameter: Relay_Type_SAFE
The parameter relaistype_SAFE defines for each output the use (relay with or without
electronics).
This parameter is determined in the OPM II by assigning an image. With a parameter change
a reset is required.

relaistype_SAFE relay without electronic At the output a relay without
electronic is connected
relay with electronic At the output a relay with
electronic is connected
Relay without electronic control (classic relay)
In this type the output including the relay coil is proofed by following tests:
· in switch off state of an output

─ for short-circuit to the external minus pole (-U)
─ for short-circuit to the external plus pole (+U)
─ for short-circuiting by alloying of the circuit breaker
─ for short-circuit of the output
─ if the protective diode of the relay is connected wrong
· in switch on state
─ if the circuit breaker is defect (does not switch through)
─ if the circuit breaker can be opened
· tests on current limitation
Relay with integrated electronic control
In this type (without relay coil) the output is proofed by following tests:
· in switch off state of an output

─ Tests for short-circuit to the external minus pole (-U)
─ Tests for short-circuit to the external plus pole (+U)
─ Tests for short-circuit of the output
· Tests on current limitation

DC0-117-2.04, Edition 04.2015
Safety Parameter
Note
Examples for external circuitry can be found in document SICAM TM – I/O Modules .

DC0-117-2.04, Edition 04.2015
Safety Parameter
9.2 Safety PLC Parameters
The safety PLC parameters are the parameters in which the user program is stored. The user
program is created by the user in the Toolset CAEx plus in function diagram technology. The
function diagram in graphic form is the common root of the diversified 2-channel control
parameters.
9.2.1 Safety Application AP-0771/SPLC01
9.2.1.1 Parameter: Safe State with Channel Errors
By means of the parameter safe state at channel error the behavior of the safety
controller with the occurrence of a channel error (e.g. fault of an input information, global error
is detected by the user program) can be parameterized by the user.

safe state at application program The safe state must be ensured through logic links
channel error in the application program.
I.e. the safety outputs must be linked with error
conditions in the application program.
If the “Global Error” is set by the application
program, the safe outputs are also switched to the
safe state in this case.
Automatic without As soon as a channel error occurs (e.g. input of the
restart inhibit DI_00 is disturbed or global error is set in the user
program), all safe outputs are switched to the safe
state. With going error the outputs are immediately
switched through again.
Automatic with restart As soon as a channel error occurs (e.g. input of the
inhibit DI_00 is disturbed or global error is set in the user
program), all safe outputs are switched to the safe
state. With going error the switching through of the
outputs must be acknowledged via the system
module TB_RESTART_INHIBIT.

DC0-117-2.04, Edition 04.2015
Safety Parameter
9.3 Standard SICAM RTUs Parameters
9.3.1 CP-2017 / CP-6014
9.3.1.1 Parameter: Failure Behavior
With the parameter Failure Behavior it is set on the BSE how it behaves after fatal errors.
It is recommended to set this parameter to “Shut down firmware” so that in the event of an
error the safe state is adopted.

Failure Behavior Firmware shutdown Default – prevents reset with
module failure
Firmware restart

DC0-117-2.04, Edition 04.2015
Safety Parameter

DC0-117-2.04, Edition 04.2015
10 Technical Data
Contents
10.1 Total System ................................................................................................ 154

10.2 Safety I/O Modules ....................................................................................... 155
10.3 Safety-Technical Characteristic Values ......................................................... 157
10.4 Declarations of Conformity............................................................................ 159

DC0-117-2.04, Edition 04.2015
Technical Data
10.1 Total System
10.1.1 Electrical Environmental Conditions
This information can be found in the following documents:

SICAM AK 3 System Description MC2-025-2.00
SICAM AK System Description MC2-021-2.03
SICAM TM System Data Sheet MC6-007-2.01
10.1.2 Climatic Environmental Conditions

10.1.3 Mechanical Environmental Conditions


DC0-117-2.04, Edition 04.2015
Technical Data
10.2 Safety I/O Modules
10.2.1 Mechanical Environmental Conditions
Parameter Value / Range Testing Class Product Class

Standard Standard
Harmonic sinusoidal 10..60Hz ±0.075mm amplitude IEC60068-2-6 1 IEC60255-21-1 1

60..150Hz 1.0g acceleration
10 (20) cycles
1..9Hz 3mm amplitude of the excursion IEC60068-2-6 IEC60870-2-2 Bm

2
9..200Hz 10m/s acceleration
2
200..500Hz 15m/s acceleration
1 cycle
Shock semi-sinusoidal 5g acceleration; 11ms duration IEC60255-21-2 1

(function)
Shock semi-sinusoidal 15g acceleration; 11ms duration IEC60068-2-27 1 IEC60255-21-2 1

(withstand) 2
100m/s acceleration; 11ms duration IEC60068-2-27 IEC60870-2-2 Bm
2x3 shock pulses
Permanent shock semi- 10g acceleration; 16ms duration IEC60068-2-27 1 IEC60255-21-2 1

sinusoidal 1000 shock pulses
Seismic harmonic sinus 1..8Hz ±3.5mm amplitude (horizontal) IEC60068-3-3 1 IEC60255-21-3 1

1..8Hz ±1.5mm amplitude (vertical)
8..35Hz 1g acceleration (horizontal)
8..35Hz 0.5g acceleration (vertical)
1 cycle
10.2.2 Climatic Environmental Conditions
Parameter Range Testing Standard
Minimum air temperature -25°C IEC 60068-2-1 Ad
Maximum air temperature +70°C IEC 60068-2-2 Bd
Temperature gradient £ 30°C/h
Relative air humidity 5....95%
Absolute air humidity £ 29g/m3
Dry heat +70°C / 4d IEC 60068-2-2
Damp heat +40°C / 4d IEC 60068-2-78
Air pressure 70..106 kPa
Storage and transport temperature -30°...+85°C

DC0-117-2.04, Edition 04.2015
Technical Data
10.2.3 Climatic Tests
Test Testing Standard

Dry cold IEC60068-2-1
Dry heat IEC60068-2-2
Moist heat IEC60068-2-78
10.2.4 Electrical Environmental Conditions
Parameter Value Testing Standard
Immunity against discharge of static electricity 8kV-L, 4kV-K IEC61000-4-2 3

(ESD)
Immunity against electromagnetic fields 20V/m IEC61000-4-3 3
Fast transient burst common 2.0 – 4.0kVs IEC61000-4-4
1.2/50µs surge common 2.0kVs IEC61000-4-5
1.2/50µs surge normal 2.0kVs IEC61000-4-5
Immunity against induced HF voltage 10V IEC61000-4-6 3
Immunity against electromagnetic fields 50Hz 100A/m IEC61000-4-8 4
Immunity against pulse shaped magnetic field 1000A/m IEC61000-4-9 5
HF test common 1.0kVs IEC61000-4-18
HF test normal 0.5kVs IEC61000-4-18
Radio interference voltage - QP 79/73dBµV EN 55011 A
Radio interference voltage – AV mean value 66/60dBµV EN 55011 A
Radio interference field strength (10m) 40/47dBµV EN 55011 A

DC0-117-2.04, Edition 04.2015
Technical Data
10.3 Safety-Technical Characteristic Values
The calculation of the safety-technical characteristic values are based on a life expectancy of
20 years, as normatively required.
Module PFH SFF MTTFd DCAVG

CP-2017/SPLC01 2.35 E-8/h 99 % 48.48 years (high) 99 %
CP-6014/SPLC01 3,36 E-8/h 99,5 % 33,93 years (high) 99 %
DI-6170 5.90 E-9/h 99.29 % 683.51 years (high) 98.64 %
DO-6270 1.404 E-9/h 99.52 % 383.00 years (high) 98.80 %
AI-6370 1.01 E-9/h 99.96 % 464.59 years (high) 95.57 %
The device type according to IEC 61508/Part 2 (chapter 7.4.4.1.3) equates type B.
The calculation of the fault rate is done for safety functions which are operated in the
operating mode with high demand rate or in the operating mode with continuous demand
(PFH). The control is suitable for this operation purpose.
Principle it is possible to use the control also for safety functions in operation mode with low
demand (PFD).
10.3.1 MTBF
The failure rates of a module are calculated from the failure rates of the components.
The manual MIL 217E serves as a basis for this. The data from MIL 217E are basically worst-
case data.
After non-elementary influencing components for the calculation have also been taken into
consideration for the function, the MTBF specified in the tables can still be multiplied with the
factor 2 to 10.
For details about the calculation, refer to

MTBF and Performance Calculation SICAM 1703 DC0-082-2.00
10.3.2 Repeat Testing Interval
During the design of the modules consideration was given to a long operating duration.
Therefore, for the Safety I/O Modules no components with limited service life are used.
Consequently, e.g. the use of electrolytic capacitors was dispensed with.
A proof test interval is not defined, the life cycle of the product is 20 years (analog modules
are restricted to 10 years). Afterwards the modules must be replaced.
If other components within the safety chain (e.g. emergency off, relay, contactors, ...) require a
proof test, then you have to comply to the resulting proof test interval.

DC0-117-2.04, Edition 04.2015
Technical Data
Note
An exception is the module AI-6370. For details refer to SICAM TM – I/O Modules (DC6-041-2.05)
Note
A function test of the application (e.g. switch off outputs on activation of emergency stop) does not apply
as proof test for the control.

DC0-117-2.04, Edition 04.2015
Technical Data
10.4 Declarations of Conformity
The declarations of conformity of the safety modules can be called up in Online Support
Products. If you have no access please consult your project manager at Siemens.
Module Item number

DI-6170 GC6-170--.XX/79
DO-6270 GC6-270--.XX/79
AI-6370 GC6-370--.XX/79

DC0-117-2.04, Edition 04.2015
Technical Data

DC0-117-2.04, Edition 04.2015
11 Guidelines for Programming
Contents
11.1 General ........................................................................................................ 162

11.2 Project Structure........................................................................................... 163
11.3 Logic ............................................................................................................ 164
11.4 POU Interface resp. Global Variable ............................................................. 165
11.5 Modifications in the Safety Application .......................................................... 166
11.6 Supported CAEx plus Data Types and Blocks............................................... 168
11.7 Basis for your own Guidelines....................................................................... 171
11.8 Application Notes ......................................................................................... 175

DC0-117-2.04, Edition 04.2015
Guidelines for Programming
11.1 General
CAEx safety restricts the scope of the programming possibilities available according to "IEC
61131-3 (2003)". This reduces the risk of programming errors.
Warning
Stick to the guidelines that are given in this section, when you are creating an application in the
programming system so that the workflows presented in this document (see section 7.) can be executed
without problems.
Note
Consult the "CAEx plus Online-Help (2012)", if you need more information on the CAEx plus guidelines.
If you need information on an IEC block or a safety block, consult the accompanying HTML documentation
of the specific block.
Start this documentation by selecting the block in the programming system CAEx plus V5.2 B320 and by
pressing the F1-Key.

DC0-117-2.04, Edition 04.2015
11.2 Project Structure
Only create the following CAEX plus-objects within a resource of the CAEX plus project:
· program instances
· type instances
Note: A type instance will be processed as program instance by CAEx safety.
Subsequently, Safety V&V displays the instance below the resource and the type below
Library with objects to be examined.
· 1 Task
· global-variable objects
Only create the following CAEx plus objects in the CAEx plus project for the programming:
· program types in FBD
· function block types in FBD
· functions in FBD
· data types
All CAEx plus objects in the scope of the resource must have unique names. This is also valid
for objects of different types, even if they are located in other folders than the resource folder.
Example: In case of type instance "GateSimulation", there must be no other object with
name "GateSimulation" in the same scope of the resource. This is also valid for the used
program types, function block types, functions and data types.
Observe the sections Logic and POU interface resp. global variable, if you create the contents
of the corresponding CAEx plus object.

DC0-117-2.04, Edition 04.2015
11.3 Logic
If you create the contents of instances resp. of POUs (program organization units = program
types, function block types and functions), the following guidelines apply:
· Create the instance/POU only in FBD (function block diagram) and with page size "A4
landscape".
· Within the instance/POU, only use objects of the following type for a programming in which
the data flow goes "from the left to the right":
─ blocks (function block instances and function invocations) with inputs on the left edge
and with outputs on the right edge
Such blocks are the following CAEx plus objects in the CAEx plus project:
− user-defined function block types resp. functions in FBD
− supported IEC blocks (see section 8.5.3.)
− safety blocks (see section 8.5.4.)
─ value fields for variables/constants for data flow "from the left to the right"
Do not use flipped value fields in CAEx plus.
─ connectors and continuations for data flow "from the left to the right"
Do not use flipped connectors/continuations in CAEx plus.
─ completely connected segments (lines) with elementary data type (see section 8.5.1.),
with safety data type (see section 8.5.2.) or with supported user-defined data types
(see in section 8.3)
─ comment fields
· All objects of one type are displayed with the same, fixed object properties in Safety V&V .
The following object properties are affected:
─ colors for background, frame, fonts
─ frame layout (e.g. width)
─ font and alignment of texts
─ graphics
─ attachment of a comment field to a drawing field object
· Do not use any of these design possibilities for depicting information that are safety
relevant (e.g. important comments in comment fields with red background color).
· Do not use the following elements for function block instances resp. function invocations
because they are not displayed in Safety V&V and hence, they cannot be reviewed:
─ attribute INLINE
─ attribute Retain

DC0-117-2.04, Edition 04.2015
11.4 POU Interface resp. Global Variable
If you create the POU interface or the variables (in instances, POUs and global-variable
objects), the following guidelines apply:
· Do not declare in-/output variables in program types and/or type instances.

· Do not declare global variables in program types and/or type instances.
· When declaring variables in instances, POUs and global-variable objects, they must be
declared as one of the following types only:
─ direct derivation of elementary data types, safety data types and user-defined data
types (see restriction about user-defined data types)
─ one-dimensional array declarations of elementary data types and safety data types
· When declaring the variable, never use the BYREF attribute and the RETAIN attribute.
· If you are declaring the following data for variables in instances, POUs and global-variable
objects, mind that they are not displayed in Safety V&V and hence, they cannot be
reviewed:
─ attribute CONST
─ comment
─ alternate I/O-names
─ technical units/scalings
─ user-defined additional information
· When declaring user-defined data types, they must be declared as one of the following
types only:
─ one-dimensional array declarations of elementary data types and safety data types
─ direct derivation of elementary data types, safety data types
─ structure declarations, if their elements consist of elementary data types or safety data
types
· Do not create internal value fields for inputs in the block image of function block types
resp. functions.
· Design the block image of function block types resp. functions in the following way to have
the block image as similar to the one in Safety V&V as possible to make the review easier:
─ Display the actual names of the in-/outputs in the block image (hence, do not display
the alternate identifiers).
─ Enter the object name as POU text to be displayed within the block image.
─ Do display the instance name for function block instances, but do not display it for
function invocations.
─ Avoid specific layout attributes, such as colors, frame layout, graphics, fonts and
alignment of texts.
All user-defined function block types resp. functions are displayed with the same, fixed
layout attributes in Safety V&V.

DC0-117-2.04, Edition 04.2015
11.5 Modifications in the Safety Application
In case of the workflow with the delta examination, consider also the effects on the explorer in
Safety V&V with activated compare view, if you modify an application in CAEx plus and you
review the modifications:
Nr. This modification in CAEx plus: has Safety V&V with compare mode displayed the
following:
1. An object (e.g. a program instance) In the explorer, the object will be displayed as:
is renamed in the CAEx plus · "new" for version "A"
project. Consequence for the corresponding tab (e.g. tab Logic
Note: If the object is a block that or Global variables): The entire contents of the object
has already been set in the logic of will be displayed as "new".
an POU or an instance, this change · "deleted" for version "B" (resp. version "C")
can affect the display in tab Logic Consequence for the corresponding tab (e.g. tab Logic
for the POU/instance; see no. 6). or Global variables): The entire contents of the object
will be displayed as "deleted".
Reason: The object name is used as key for the
comparison of the project contents (the contents of the
objects).
2. A variable in an existing In tab Variables, the variable will be displayed as:
POU/instance is renamed. · "new" for version "A"
· "deleted" for version "B" (resp. version "C")
Reason: The name of the variables is used as key for the
comparison of the variables.
3. A variable in an existing global- In tab Global variables, the global variable will be
variable-object is renamed. displayed as:
· "new" for version "A"
· "deleted" for version "B" (resp. version "C")
Reason: The name of the global variables is used as key
for the comparison of the global variables.
4. A structure element in an existing In tab Data type, the structure element will be displayed
data type is renamed. as:
· "new" (in the field on the left) for version "A".
· "deleted" (in the field on the right) for version "B" (resp.
version "C")
Reason: The name of the structure elements is used as
key for the comparison of the data type content.
5. The instance name of a block (of a In tab Logic, the block will be highlighted by:
function block instance resp. of a
function invocation) has been · (as new element) for version "A".
changed within an existing · (as deleted element) for version "B" (resp.
POU/instance. version "C").
The instance name can Reason: The instance name is used as key for the
automatically and manually be comparison of blocks within the logic. A list of all logic
changed in CAEX elements and their key for the comparison can be found in
Example for the automatic the CAEx safety online-help.
change: You replace the existing
block by another one.
Example for the manual change:

You enter a new instance name
for the existing block.
Note: If you correct the instance
name to an instance name
previously assigned, the block is
highlighted as code-relevant
change; see no. 6).

DC0-117-2.04, Edition 04.2015
6. Special case "combining no. 1) and In tab Logic for the POU/instance in which the block is set,
no. 5)": the block is highlighted by (as code-relevant
· See no. 1): A block (a function change).
block instance resp. function Reason: The instance name is used as key for the
invocation) is renamed in the comparison of blocks within the logic.
project.
· This block has already been set
in the logic of an POU or an
instance. A new instance name is
automatically entered by updating
the POU contents in CAEx plus;
see no. 5).
· See no. 5): You correct the new
instance name to the one
previously assigned.

DC0-117-2.04, Edition 04.2015
11.6 Supported CAEx plus Data Types and Blocks
When programming, you will be using "ready-made" CAEx plus data types and CAEx plus
blocks. The subsections inform about specific guidelines and restrictions applying for these
CAEx plus data types and CAEx plus blocks.
Warning
Use the supported CAEx plus blocks only with the range of values that is valid for the block.
11.6.1 Elementary Data Types
Only use the following elementary data types when programming:
binary, signed unsigned floating point of time and period, date

bit string integer integer point and
character string
(1)
BOOL SINT USINT REAL TIME
(1)
BYTE INT UINT LREAL DATE
(1)
WORD DINT UDINT TIME_OF_DAY
(1)
DWORD DATE_AND_TIME
STRING (with a length of 128
byte incl. null terminator)
(1)
… see the following note
Warning
In case of data types TIME, DATE, TIME_OF_DAY und DATE_AND_TIME you must use only integer
values (resolution 1 ms) within the following range of values:
lower limit: –7.730.063.005.354.400 ms
upper limit: 7.730.063.005.354.400 ms
In case of all other data types, you must use the values within the range of values valid for CAEx plus.
See "CAEx plus Help (2012)", keyword "Data Type, Range of Values"
Segments (lines) type-coded with one of these data types are displayed in Safety V&V with a
color appropriate for the data type. This color is also used for connected value fields,
connectors and continuations.
11.6.2 Safety Data Types
Warning
The safety data types are derivations of the corresponding elementary data type. For instance, SAFEBOOL
is the derivation of BOOL.
The safety data types SAFEINT and SAFEREAL serve only to emphasize visually safe signals and safe
information flows. They do not realize a safeguarding of the signal flow.
The safety data type SAFEBOOL can be used to safeguard the signal flow (see the following note on
SAFEBOOL).
Consider that if the SAFEBOOL has an invalid condition, the processing on the controller will be aborted at
once.

DC0-117-2.04, Edition 04.2015
Note
It is possible to recognize invalid conditions, when using SAFEBOOL.
Fixed bit patterns are assigned to (safe) TRUE and (safe) FALSE on the controller. If blocks with
inputs/variables of data type SAFEBOOL are processed and there are deviations of the assigned patterns
during this processing, the controller recognizes such deviations and aborts the processing.
Segments (lines) type-coded with one of the safety data types are displayed in Safety V&V
with color "Yellow". This color is also used for connected value fields, connectors and
continuations.
Only use the following safety data types when programming:
binary, bit string signed integer Floating point

SAFEBOOL SAFEINT SAFEREAL
The safety data types are available in the sub-library "DataType" of the safety library
"SafetyIEC61131-3". They can be used like the elementary data types in CAEx plus for the
project engineering (e.g. enter the name in field Declaration when declaring the variable).
11.6.3 Supported IEC Blocks
The IEC blocks are functions and function blocks as described in "IEC 61131-3 (2003)" resp.
provided as enhancement for it. They are contained in the sub-libraries of the library
"SICAM1703_Safety". Exceptions: "SafetyIEC61131-3”, "SafetyIEC61131-3-Ext”, "System
Function”
Warning
Use appropriate design measures to make sure that the supported IEC blocks are only connected with
values that are valid for the input data type of the IEC block and that are within the range of values of the
output data type of the IEC block.
This must be applied in particular, if you are using the "Convert" blocks from the IEC libraries. Mind the
precision of the values (integer vs. floating point) and the admissible range of values (values not outside
the upper/lower limit).
Apply the following rule for the admissible range of values:
If the input data type has a bigger range of values than the output data type, the inputs of the block must
only be connected with values within the smaller range of values of the output data type.
If uncertain, do not use the "Convert" blocks from the IEC libraries.
Example how values outside the upper/lower limit might arise: The "Convert" block AtoInt is
connected with data type REAL. (Thus, a value in format REAL is converted to format INT.)
In this case, make sure that only values admissible for INT (lower limit: -32768, upper limit: 32767)
are connected to the input. To do so, check the admissible values regarding upper/lower limit by using
an appropriate "Compare" block (EQ, GE, GT, LE, LT, NE) in the logic.

DC0-117-2.04, Edition 04.2015
11.6.4 Safety Blocks
Warning
Only use the safety blocks when programming for emphasizing the safety-related logic.
The safety blocks do not include any integrated safety function, such as redundant calculations by
comparators.
Consider that the ENO output of a safety block is set to FALSE and a global error is set as central error
information, if a problem occurs during the processing of this safety block (such as the overflow with an
adder block). The outputs of the faulty safety block are set to FALSE resp. 0 as well.
Use block SI_GetGlobalError (available in the safety library "Safety-IEC61131-3" – sub-library
"GlobalError") in the application to retrieve the state of the global error: Output OUT1 of
SI_GetGlobalError is set to TRUE.
If you are using the blocks SI_ResetGlobalError resp. SI_SetGlobalError to change the state of
the global error, use appropriate design measures to make sure that the change does not compromise or
influence the safety function of the E/E/PE system.
If uncertain, do not use these blocks.
The safety blocks are variants of the appropriate IEC blocks resp. enhancements for it. They
are contained in the safety library "SafetyIEC61131-3", which is available in the object
"SICAM1703_Safety".
The following characteristics help to distinguish the safety blocks from the IEC blocks in the
programming:
· The background color of a safety block is yellow.

· The object name and the instance name of a safety block starts with prefix "SI_".
Observe that the safety blocks may only be connected with safety data types. Exception:
Other data types are possible for the safety conversion blocks and the safety timer-blocks only
(available in the corresponding sub-libraries of "SafetyIEC61131-3").
11.6.5 Safety Conversion Blocks
A safety conversion block converts the elementary data type BOOL, INT or REAL into the
safety data type SAFEBOOL, SAFEINT or SAFEREAL and vice versa.
The safety conversion blocks are available in the safety library "SafetyIEC61131-3", namely in
sub-library "Convert".
Warning
If a standard signal is converted to a safe signal (by the safety conversion block SI_BOOL_TO_SAFEBOOL,
SI_INT_TO_SAFEINT or SI_REAL_TO_SAFEREAL), use the appropriate design measures to make sure
that the conversion does not compromise or influence the safety function of the E/E/PE-system.
Example for design measure: usage of 2-out-of-3-logic

DC0-117-2.04, Edition 04.2015
11.7 Basis for your own Guidelines
SIEMENS recommends to specify your own guidelines for the following items in your
development process, although CAEx safety has no restrictions for them:
· maximum size for project

· maximum size for block
Example: No more than 10 logic pages within a POU so that the review of a single POU is
short.
· name conventions in order to avoid misunderstandings
This applies in particular to names of variables and to names of structure elements (in
data types).
Example: no names that are reserved keywords according to "IEC 61131-3 (2003)"
11.7.1 Reserved Keywords according to IEC
The following tables provide an overview of the reserved keywords according to "IEC 61131-3
(2003)".
Please observe that the case of characters is not significant in keywords. For instance, the
terms "FOR" and "for" are equivalent.
Table C.2 – Keywords according to "IEC 61131-3 (2003)"

Keywords Clause according to "IEC 61131-3
(2003)"
ACTION...END_ACTION 2.6.4.1
ARRAY...OF 2.3.3.1
AT 2.4.3
CASE...OF...ELSE...END_CASE 3.3.2.3
CONFIGURATION...END_CONFIGURATION 2.7.1
CONSTANT 2.4.3
Data type names 2.3
EN, ENO 2.5.1.2, 2.5.2.1a)
EXIT 3.3.2.4
FALSE 2.2.1
F_EDGE 2.5.2.2
FOR...TO...BY...DO...END_FOR 3.3.2.4
FUNCTION...END_FUNCTION 2.5.1.3
Function names 2.5.1
FUNCTION_BLOCK...END_FUNCTION_BLOCK 2.5.2.2
Function block names 2.5.2
IF...THEN...ELSIF...ELSE...END_IF 3.3.2.3
INITIAL_STEP...END_STEP 2.6.2
NOT, MOD, AND, XOR, OR 3.3.1
PROGRAM...WITH... 2.7.1
PROGRAM...END_PROGRAM 2.5.3
R_EDGE 2.5.2.2

DC0-117-2.04, Edition 04.2015
Table C.2 – Keywords according to "IEC 61131-3 (2003)"

Keywords Clause according to "IEC 61131-3
(2003)"
READ_ONLY, READ_WRITE 2.7.1
REPEAT...UNTIL...END_REPEAT 3.3.2.4
RESOURCE...ON...END_RESOURCE 2.7.1
RETAIN, NON_RETAIN 2.4.3
RETURN 3.3.2.2
STEP...END_STEP 2.6.2
STRUCT...END_STRUCT 2.3.3.1
TASK 2.7.2
TRANSITION...FROM...TO...END_TRANSITION 2.6.3
TRUE 2.2.1
TYPE...END_TYPE 2.3.3.1
VAR...END_VAR 2.4.3
VAR_INPUT...END_VAR 2.4.3
VAR_OUTPUT...END_VAR 2.4.3
VAR_IN_OUT...END_VAR 2.4.3
VAR_TEMP...END_VAR 2.4.3
VAR_EXTERNAL...END_VAR 2.4.3
VAR_ACCESS...END_VAR 2.7.1
VAR_CONFIG...END_VAR 2.7.1
VAR_GLOBAL...END_VAR 2.7.1
WHILE...DO...END_WHILE 3.3.2.4
WITH 2.7.1
Table 8 – Date and time of day literals according to "IEC 61131-3 (2003)"
Feature description Prefix Keyword
Date literals (long prefix) DATE#
Date literals (short prefix) D#
Time of day literals (long prefix) TIME_OF_DAY#
Time of day literals (short prefix) TOD#
Date and time literals (long prefix) DATE_AND_TIME#
Date and time literals (short prefix) DT#
Note
The following table 10 is an extract of "IEC 61131-3 (2003)" concerning the keywords.
The table 10 in "IEC 61131-3 (2003)" is containing additional information on the range of values and
precision of representation per data type.
Table 10 – Elementary data types according to "IEC 61131-3 (2003)"

Keyword Data type
BOOL Boolean

DC0-117-2.04, Edition 04.2015
Table 10 – Elementary data types according to "IEC 61131-3 (2003)"

Keyword Data type
SINT Short integer
INT Integer
DINT Double integer
LINT Long integer
USINT Unsigned short integer
UINT Unsigned integer
UDINT Unsigned double integer
ULINT Unsigned long integer
REAL Real numbers
LREAL Long reals
TIME Duration
DATE Date (only)
TIME_OF_DAY oder TOD Time of day (only)
DATE_AND_TIME oder DT Date and time of Day
STRING Variable-length single-byte character
string
BYTE Bit string of length 8
WORD Bit string of length 16
DWORD Bit string of length 32
LWORD Bit string of length 64
WSTRING Variable-length double-byte character
string
The generic data types are keywords as well and identified by the prefix ANY.
Table 11 – Hierarchy of generic data types according to "IEC 61131-3 (2003)"

ANY
ANY_DERIVED (derived data types)
ANY_ELEMENTARY
ANY_MAGNITUDE
ANY_NUM
ANY_REAL
LREAL
REAL
ANY_INT
LINT, DINT, INT, ULINT, SINT
ULDINT, UDINT, UINT, USINT
TIME
ANY_BIT
LWORD, DWORD, WORD, BYTE, BOOL
ANY_STRING
STRING
WSTRING
ANY_DATE

DC0-117-2.04, Edition 04.2015
Table 11 – Hierarchy of generic data types according to "IEC 61131-3 (2003)"

DATE_AND_TIME
DATE, TIME_OF_DAY
Examples for terms that are delimited by keywords T# or TIME#.
Table 7 – Duration literal features according to "IEC 61131-3 (2003)"

Feature description Example
Duration literals without underlines:
short prefix T#14ms T#-14ms T#14.7sT#14.7m
T#14.7h t#14.7d t#25h15m
t#5d14h12m18s3.5ms
long prefix TIME#14ms TIME#-14ms time#14.7s
Duration literals with underlines:
short prefix t#25h_15m t#5d_14h_12m_18s_3.5ms
long prefix TIME#25h_15m
time#5d_14h_12m_18s_3.5ms

DC0-117-2.04, Edition 04.2015
11.8 Application Notes
11.8.1 Behavior of the Module Outputs when using the EN Input
If the EN input of a module is used, the outputs of this module must not be wired directly with
signals. In this case a MOVE module must be connected between module output and signal.

DC0-117-2.04, Edition 04.2015

DC0-117-2.04, Edition 04.2015
A Checklists
Contents
A.1 Planning ....................................................................................................... 177

A.2 Programming................................................................................................ 178
A.3 Installation .................................................................................................... 179
A.4 Commissioning ............................................................................................. 179
A.5 Maintenance, Modification ............................................................................ 181
A.1 Planning
Tasks Yes No
Have relevant points of the risk analysis been observed and implemented? □ □
Are the process requirements defined? □ □
e.g. response times, error reactions
Have the following been defined/described according to the standard used (EN □ □
ISO 13849-1 or EN 62061):
− The entire safety functions?
− The implementation of the requirements?
Has the safe startup been planned for the plant/machine? □ □
e.g. prevent automatic startup
Are all required operating states of the plant determined? □ □
Are the existing operating elements of the plant named? □ □
Are the existing accessory equipment of the plant named? □ □
Is it determined, which locally valid regulations must be observed? □ □
Are the test specifications defined for commissioning? □ □
Have the safety measures been described separately? □ □
Has a spatial cordoning off of the plant or danger zone been planned? □ □
Has password protection been provided? □ □
Has maintenance and test of the plant, modules been planned after □ □
commissioning?
Planning of the combination of standard and safety signals

Has the proper intended use of safe and non-safe signals been observed in the □ □
application program.
e.g. non-safe signals do not influence the safe route?
Has the use been described? □ □
e.g. I/O assignment
Have special plausibility tests been planned, if non-safe signals or variables □ □
influence safety functions?
Has a special test procedure been defined for the commissioning? □ □

DC0-117-2.04, Edition 04.2015
Checklists
Create wiring diagram

Have the modules of the SICAM systems been documented? □ □
Master module type, type of the input/output modules (e.g. module with analog
outputs, module with digital outputs)
Has the connection type of the sensors been defined? □ □
Has the method of fault information indications of the plant been determined? □ □
e.g. illuminated signal lamp, plain text display, computer connection
Has the assignment of the test clock pulses and inputs been defined, setting □ □
time of the inputs observed?
Has it been checked where an exclusion of a fault is possible through suitable □ □
line routing?
Has a test of the sensors taken place with sensor clocking? □ □
Have the EMC measures been observed? □ □
Planning of the function “Force Variables” for commissioning

Has a separate risk analysis been carried out? □ □
Have the implementations in chapter Guidelines for working with SICAM RTUs □ □
Safety been observed?
Date: _____________________ Signature: ____________________________________
A.2 Programming
Tasks Yes No
Have relevant points from the risk analysis been observed and implemented? □ □
Selection of the certified safety modules

Have certified safety module been used exclusively for the safety functions? □ □
Has it been determined, which operating elements must be supported? □ □
Have the necessary plausibility checks been carried out for the safety-relevant □ □
signals in the application program?
e.g. anticoincidence test, evaluation of the error information of the inputs or
outputs
Define structure of the user program

Have the safety requirements determined in the planning phase been □ □
observed?
Have the generally applicable programming rules been observed? (e.g. □ □
according to EN 13849-1)
Has the mixed use of safe and non-safe signals, variables been defined? □ □
Has the meaning of safe signals, variables been defined? □ □
Planning of the combination of standard and safety signals
Has the proper intended use of safe and non-safe signals been observed in the □ □
application program.
e.g. non-safe signals do not influence the safe route?

DC0-117-2.04, Edition 04.2015
Checklists
Have safety modules with mixed input interface been adequately commented? □ □
(e.g. I/O assignment)
Have special plausibility tests been planned, if non-safe signals or variables □ □
influence safety functions?
Have special test procedures been defined for the commissioning? □ □
System Check
Is the target configuration suitable for the required function? □ □
Does the I/O assignment including hardware suit the required function? □ □
Have the test clock pulses been configured? □ □
Has the preliminary cycle time for tasks been specified, cycle time optimized □ □
during commissioning?
Has a device naming been carried out for all devices in the project? □ □
Have hints/notes (Errors, Warnings) been observed during the realization of the □ □
project?
Have hints/notes (Diagnostics) been observed during parameter loading? □ □
Has an Offline Test been performed before loading the application program? □ □
Date: _____________________ Signature: ____________________________________
A.3 Installation
Tasks Yes No
Have the installation guidelines been observed? □ □
Has the wiring diagram been adhered to? □ □
Are inputs that are not assigned in the I/O assignment not wired? □ □
Have all the rules and regulations for the prevention of accidents valid for the □ □
place of use been observed and adhered to?
Have all regulations concerning protective measures valid for the place of use □ □
been observed and adhered to?
Date: _____________________ Signature: ____________________________________
A.4 Commissioning
Tasks Yes No
Have the assembly instructions been created under consideration of the risk □ □
analysis?
Have the safety measures been described? □ □
Has commissioning been performed based on the test specification? □ □
e.g. signal tests for inputs and outputs, functional test of the user program

DC0-117-2.04, Edition 04.2015
Checklists
Safety functions and error detection equipment

Have execution times been optimized? □ □
Have all specified safety functions and error detection equipment been tested □ □
completely? (a purely functional test is not sufficient!)
Examples:
− Test 2-channel Emergency-Stop for errors in a channel
− Simulate cross-connections
− Simulate short circuits and interruptions on lines
− Perform measurement of the overtravel time/distance
− Connect redundant sensors differently
− Simulate single-channel switching of stuck proximity switches
− Test clock pulse wiring
− Check for all safety variables, whether the associated Safety-Hardware
Inputs/Outputs are suitable for the safety requirement
− Prove, that in the event of an error the safe state is reached
Has the adherence to the maximum system response time been tested? □ □
Safety modules with mixed input interface

Have plausibility tests been carried out that were defined for the safety modules □ □
with mixed input interface?
Have test procedures been applied that were defined for the safety modules □ □
with mixed input interface?
Have activities and tests been logged? □ □
Force Variables
Have relevant points from the separate risk analysis been observed? □ □
Have the implementations in chapter Guidelines for working with SICAM RTUs □ □
Safety been observed?
Has machine or danger zone been spatially cordoned off? □ □
Has attention been given to the time limit of “Force Variables”? □ □
− The function “Force Variables” must be stopped manually immediately after
setting into operation.
− The function “Force Variables” is stopped automatically after 12 hours at
the latest.
General
Have the regulations been observed? □ □
e.g. Machinery Directive
Has a backup copy of the original project been created and saved according to □ □
the project backup plan?
Has the checksum of the original project been documented? □ □
Has the commissioning been documented? □ □
Has the safety function been approved by an independent body or third person? □ □
Has it been checked whether the correct version of the application program is □ □
running in the destination system?
Date: _____________________ Signature: ____________________________________

DC0-117-2.04, Edition 04.2015
Checklists
A.5 Maintenance, Modification
Tasks Yes No
Have the SICAM systems been switched to the STOP state before the □ □
exchange?
Have the safety requirements been adhered to for the following activities? □ □
(see corresponding checklists):
− Planning
− Programming
− Installation
− Commissioning
Have the specifications in the system description been observed during the □ □
exchange of the memory card (SD card) on a SICAM system?
Have the modifications been documented? □ □
Has the (re-) commissioning been carried out and documented? □ □
(see checklist “Commissioning”)
Has a backup copy of the original project been created and saved according to □ □
the project backup plan?
Has the checksum of the new original project been documented? □ □
Date: _____________________ Signature: ____________________________________

DC0-117-2.04, Edition 04.2015
Checklists

DC0-117-2.04, Edition 04.2015
B Installation Declaration

DC0-117-2.04, Edition 04.2015
Installation Declaration

DC0-117-2.04, Edition 04.2015

DC0-117-2.04, Edition 04.2015
Pages 1-4 are the german versoin of the installation declaration.

Pages 9-11 of the installation declaration are identical with Appendix C, TÜV Certificate.

DC0-117-2.04, Edition 04.2015
C TÜV Certificate

DC0-117-2.04, Edition 04.2015
TÜV Certificate

DC0-117-2.04, Edition 04.2015
TÜV Certificate

DC0-117-2.04, Edition 04.2015
TÜV Certificate

DC0-117-2.04, Edition 04.2015
Literature
Literature
IEC 61131-3 (2003) standard IEC 61131 part 3 "Programmable Controllers - Programming
Languages"; basis for a standardized programming for PLCs considering the modern
concepts of software technology, International Electrotechnical Commission, published in
2003
IEC 61508 (2010) standard "Functional safety of electrical/electronic/programmable

electronic safety-related systems", International Electrotechnical Commission (IEC), published
in 2010; safety standard that describes the basic, complete lifecycle of safety-related systems
IEC 61508-1 (2010) standard "Functional safety of electrical/electronic/programmable

electronic safety-related systems", part 1: General requirements, International Electrotechnical
Commission (IEC), published in 2010

electronic safety-related systems", part 2: Requirements for
electrical/electronic/programmable electronic safety-related systems, International
Electrotechnical Commission (IEC), published in 2010

electronic safety-related systems", part 4: Definitions and abbreviations, International
Electrotechnical Commission (IEC), published in 2010
CAEx plus Help (2012) product documentation "CAEx plus Help" V5.2 B320, published in
2012 for CAEx plus version 5.2 build 320; The CAEx plus help can be started from within the
application CAEx plus V5.2 B320 and contains information how to use the programming
system CAEx plus.
CAEx safety Online-Help (2012) product documentation "CAEx safety Online-Help"

V2.0, published in 2012 for CAEx safety version 1.0; The CAEx safety online-help can be
started from within the applications Safety V&V V1.0 and Safety Monitor V1.0. It contains
information how to start the CAEx safety components from within the programming system
and how to use their graphical user interface.

DC0-117-2.04, Edition 04.2015
Literature

DC0-117-2.04, Edition 04.2015
Glossary
A
AU
Automation Unit
Application program
Logical arrangement of all program language elements and constructs, that are required for the intended
signal processing for the control of a machine or of a process with a PLC system (acc. to
IEC 61131-12.1).
With CAEx plus application programs for open-/closed-loop control functions are created. An application
program comprises the task(s) and the related program instances and type instances. An application
program is executed by a resource ( CPU).
Article 95 EC Treaty
Article 95 of the EC Treaty defines analogously, that the member states must all implement the European
Directives referring to this article into national law. These directives are, expressed another way, to be
translated in identical content into national law and represent quality requirements on goods. No member
state may create, by means of national regulations, conditions that prescribe higher or lower
specifications on goods.
Automation unit
An automation unit is a modular structured device for the acquisition, processing and output of process
information. It communicates in automation networks via a serial or Ethernet protocols with other
automation units or control center systems.
An automation unit consists of at least 1 mounting rack or 1 DIN rail (depending on system), 1 power
supply and 1 basic system element, as well as optional peripheral elements and optional protocol
elements.

Enables the secured (hamming distance 4), serial, system-internal communication between the basic
system element and the peripheral elements
B
Basic system element
System element for processing of information according to different criterions (e.g. automation,
telecontrol, etc.) and for the administration of system functions (e.g. parameter, diagnosis, etc).
BSE
Basic System Element (master control element, processing and communication element)
Black channel
A transmission channel protected with the PROFISafe Layer on any transmission link not adequately
protected for SIL.
Is an unsafe transmission medium over which the data are however be transmitted corruption-proof. A
"black channel" does not ensure that the data are transmitted safely, rather ensures that a corruption of
the data caused by the transmission link is detected.
CAEx plus
Tool for the creation of application programs (Computer Aided Engineering), based on the tool logiCAD ®
from the company logi.cals ®
CAEx safety
Toolset for the safety-relevant tools such as "Safety V&V", "Safety Monitor" and "Safety Converter" of the
company logi.cals.

DC0-117-2.04, Edition 04.2015
Glossary
Checksum
data computed from a data block in order to detect errors that might have occurred during data
transmission or storage. The data integrity can be checked by recomputing the check sum and comparing
it with the original one. If they match, it can be assumed that the data were not modified (with or without
intention). The checksum value depends on the representation of the data. That means, different
checksum values are computed, if the data is mapped in XML format or in binary format. CAEx safety
uses the CRC32 algorithm for calculating the checksum .Compare "fingerprint"
Configuration
Configuration is used in a multiple meaning:
a) engineering of the configuration of an automation unit in the engineering tool
b) physical aligning and mounting of the configured hardware
– plugging in the slot defined by the configuration (slot addressing), or
– setting the address defined by the configuration, and plugging in an arbitrary slot (adjustable address)
Controller
The controller is a PE device that is part of the E/E/PE system. It is being used to control a machine or
plant, its programming is application-specific. See also "PE (programmable electronic)"
D
Delta examination
examination of a modified application during which the scope of the examination is restricted according to
the modifications. A major part of the delta examination is the complete identification of the functions that
are affected directly or indirectly. The scope of the delta verification and of the delta validation is deduced
from this identification.
Depassivation of channels
Dependent on the error class certain errors can also be remedied by the user without the exchange of a
module (e.g. wiring errors, configuration/programming errors). Following localization of the error a further
cyclic test is carried out. If the result of the running test of the module is, that there is no further error
present, the process values are then reactivated (“Depassivation”) and given the status “valid”.
Depassivation is only possible for input channels with errors of the error class < > system errors.
E/E/PE system (electrical/electronic/programmable electronic system)

Definition according to "IEC 61508-4 (2010)":
system for control, protection or monitoring based on one or more electrical/electronic programmable
electronic (E/E/PE) devices, including all elements of the system such as power supplies, sensors and
other input devices, data highways and other communication paths, and actuators and other output de-
vices
See also "controller"
The term "E/E/PE system” within this document is always a stand-in for the automation system SICAM
safety.
EM II
Configuration tool of SICAM TOOLBOX II (Engineering Manager II)
EUC (equipment under control)

equipment, machinery, apparatus or plant used for manufacturing, process, transportation, medical or
other activities
Examined user-objects
POUs (program types, function block types, functions) or data types that the supplier has already
verified/validated and that has been made an "examined user-object". Examined user-objects are not a
fixed part of the controller; compare "system blocks" and "system data types".

DC0-117-2.04, Edition 04.2015
Glossary
Firmware
Program that is not changeable by the user, that adds a predefined and parameter-settable functionality
to the hardware
Fingerprint
A fingerprint is the mapping of a bigger data block to a much shorter character string and serves to
identify this data block. In CAEx safety, the fingerprint is computed for the contents of the data and is
independent from the representation. This means, the same fingerprint values are computed, no matter if
the data is mapped in XML format or in binary format. Compare "checksum"
Functional safety
Functional safety is the capability of an electrical, electronic or programmable electronic system to remain
in the safe state or to switch to a safe state with the occurrence of random and/or systematic failures with
dangerous effect.
Part of the overall safety, relative to the machine and the machine control system, that depends on the
correct function of the SRECS (safety-related electrical control system), safety-related systems of another
technology and external equipment for the reduction of risks.
Function diagram
Graphical program for open-/closed-loop control functions according IEC 61131-3
FUD
Function diagram
FW
Firmware
IOA
Information Object Address
N
NIP
Network Interface Processor
M
Module Number
System-technical identification of a system element within an automation unit, part of the IOA in a
message with system-technical addressing. The other parts of the IOA are the value number and the
subaddress.
MTBF
MTBF = Mean Time Between Failure
MTTFd
MTTF = Mean Time To Failure
OPM II
Central SICAM TOOLBOX II configuration tool (Object-oriented Process Data Manager)
other risk reduction measure

measure to reduce or mitigate risk that is separate and distinct from, and does not use, E/E/PE safety-
related systems

DC0-117-2.04, Edition 04.2015
Glossary
Passivation
One regards the “passivation” of a channel as the activation of the process value “0” with error status “1”
(“invalid”).
Passivation of the channels can be controlled both from the basic system element as well as from the I/O
module itself, for example after the detection of errors in the self-tests or following the occurrence of
communication errors.
Module-wide errors lead to the passivation of all channels of the relevant module. With the occurrence of
channel-specific errors only the affected channel data are passivated.
Passivation of channels can take place in every operating state.
PBA
Peripheral Module Address
The peripheral module address is set on the peripheral element by means of a rotary switch. A maximum
of 16 PE's can be configured on one Ax 1703 peripheral bus.
PE
Peripheral Element
PE (programmable electronic)
based on computer technology which may be comprised of hardware, software, and of input and/or out-
put units
Note: This term covers microelectronic devices based on one or more central processing units (CPUs)
together with associated memories, etc.
Example: The following are all programmable electronic devices:
· microprocessors;
· micro-controllers;
· programmable controllers;
· application specific integrated circuits (ASICs);
· programmable logic controllers (PLCs);
· other computer-based devices (for example smart sensors, transmitters, actuators).
Peripheral element
The peripheral element is a supplementary system element for process data acquisition and/or control of
actuators. It communicates via the Ax-PE-Bus with the basic system element.
Performance Level
Discrete Level, that specifies the capability of safety-related parts of a control system to execute a safety
function under predictable conditions: from PL “a” (highest failure probability) to PL “e” (lowest failure
probability).
PFHD
Probability of dangerous failure per hour
Probability of a dangerous failure per hour.
PL
Performance Level
PLC
Programmable Logic Controller
POU
Program-Organisation-Units = program types, function block types, functions
PRE
Protocol Element
PROFIsafe
Safety-orientated bus profile of PROFIBUS DP/PA for the communication between the safety program
and the safe peripherals.

DC0-117-2.04, Edition 04.2015
Glossary
Program sequence monitoring

Used for the control of the synchronicity at defined points of two programs running redundantly.
Protocol element
The protocol element is a supplementary system element for communication with other automation units
or control systems. It communicates via the internal bus (ZBG-Bus) with the basic system element.
RAMS
Reliability, Availability, Maintainability and Safety
Recommended (R)
A technique or measure is recommended for a corresponding Safety Integrity Level. This value can range
from a low to a high recommendation. [IEC 61508-3, Annex A].
Release
organizational measure (activity of an authorized person) by which the application is released as "ready
for operation" The release state of the application is recorded in Safety V&V by the V&V state "Release".
Review
static examination of an application in the course of which one/several natural and competent persons
examine the application (e.g. by using Safety V&V). Usually, reviews are part of the verification. Your
company's guidelines define whether the verification consists of review and test (e.g. unit tests) or review
only.
Safety Application
A user program created by CAEx plus and verified, validated and protected against corruption by CAEx
safety.
Safety Firmware
Is a firmware which has been developed according to the requirements of Functional Safety and
processes the Safety Application.
Safety Parameters
In this document Safety Parameters is used as summarization of the safe user program and the safe
parameters.
safe
free of unwarranted risks
Safe state
Basis of the safety concept in F-systems is, that a “safe state” exists for all process variables. With digital
I/O peripherals that is e.g. the value ‘0’.
safety-related system
designated system that both
· implements the required safety functions necessary to achieve or maintain a safe state for the EUC;
and
· is intended to achieve, on its own or with other E/E/PE safety-related systems and other risk reduction
measures, the necessary safety integrity for the required safety functions
Safety function
function to be implemented by an E/E/PE safety-related system or other risk reduction measures, that is
intended to achieve or maintain a safe state for the EUC, in respect of a specific hazardous event
Safety integrity
probability of an E/E/PE safety-related system satisfactorily performing the specified safety functions
under all the stated conditions within a stated period of time

DC0-117-2.04, Edition 04.2015
Glossary
Safety integrity level (SIL)

discrete level (one out of a possible four), corresponding to a range of safety integrity values, where
safety integrity level 4 has the highest level of safety integrity and safety integrity level 1 has the lowest
The higher the level of safety integrity, the lower the probability that the safety-related system will fail to
carry out the specified safety functions or will fail to adopt a specified state when required.
Safety lifecycle
necessary activities involved in the implementation of safety-related systems, occurring during a period of
time that starts at the concept phase of a project and finishes when all of the E/E/PE safety-related
systems and other risk reduction measures are no longer available for use
Safe operation
Operating state of the system, in which safety-oriented communication is possible over safety messages
and safety functions are guaranteed.
SD card
Secure Digital Memory Card; up to 2 GB storage capacity
SICAM TOOLBOX II
PC-based set of tools for configuration and service of SICAM automation units
SIL
Safety Integrity Level
Software lifecycle
activities occurring during a period of time that starts when software is conceived and ends when the
software is permanently disused
SRCF
Safety-Related Control Function
Control function
Safety-related control function executed by SRECS with a defined Integrity Level, which is intended to
maintain the safe state of the machine or prevent an immediate increase of risks.
SRECS
Safety-Related Electrical Control System
Safety-related electrical control system of a machine (according to EN 62061), the failure of which leads
to an immediate increase of risks.
SRP/CS
Safety-Related Parts of Control System
Safety-related part of a control system (according to EN ISO 13849-1), that responds to safety-related
input signals and generates safety-related output signals.
SSE
Supplementary system element
SSM
Tool for the administration of SICAM TOOLBOX II data (Siemens Stammdaten Manager); reserved for
developer of Siemens AG.
Status "A", Status "B", Status "C"

Designations from Safety V&V in connection with the delta examination:
· Status "A" is the last status generated in the SICAM TOOLBOX II.
This corresponds with the current application status and can be subjected to a review with Safety
V&V.
· Status "B" is the last status loaded in the destination system.
· Status "C" is the last status released in the SICAM TOOLBOX II.
During the delta examination status “A” is compared with one of the other two statuses.

DC0-117-2.04, Edition 04.2015
Glossary
Standard operation
Operating state of the system, in which the safety functions are not guaranteed.
Standard application
Is the user program of the standard firmware.
Standard firmware
Is a firmware which cannot be loaded according to the requirements of Functional Safety.
Supplementary system element

Supplementary system elements are situated hierarchically below basic system elements; there are
peripheral elements, and protocol elements
System element
Functional unit consisting of hardware and firmware
System blocks
POUs (function block types, functions) that are a fixed part of the controller. Compare "examined user-
objects" and "system data types".
System data types

data types that are a fixed part of the controller. See also "system blocks". A system data type is
displayed under library "System blocks" of Safety V&V as well.
T
Target system
Synonym for "controller"; This term is used, if the description refers to a concrete controller type.
Test
systematic examination of the functionality of an application by a natural and competent person. Usually,
the dynamic test is meant with the application being executed. Your company's guidelines define whether
the verification and/or validation include (dynamic) tests.
TM
Terminal Module; Module for mounting on a DIN-rail
TM-Bus
Bus between peripheral control module (Master) and I/O-module (Slave)
V
Validation, validate
documented, objective line of argument that an application correctly meets the specific requirements (the
original aims of the customer) for the indented usage. The validation state for the application can be re-
corded in Safety V&V by the V&V state "Validation".
Confirmation by examination and provision of objective evidence that the particular requirements for a
specific intended use are fulfilled […] Therefore, for example, software validation means confirming by
examination and provision of objective evidence that the software satisfies the software safety
requirements specification.
· Does the behavior of the functions meet expectations?

· Do functions indirectly affected behave correctly?
Verification, verify
formal, objective examination of an application whether it and its used elements are conform to a
specification and/or whether they fulfill the given specification. The verification state for the application can
be recorded in Safety V&V by the V&V state "Verification".
Confirmation by examination and provision of objective evidence that the requirements have been fulfilled;
In the context of this standard, verification is the activity of demonstrating for each phase of the relevant
safety lifecycle (overall, E/E/PE system and software), by analysis, mathematical reasoning and/or tests,
that, for the specific inputs, the deliverables meet in all respects the objectives and requirements set for
the specific phase.

DC0-117-2.04, Edition 04.2015
Glossary
· Are all required functions contained?

· Are only the desired functions contained?
· Have the functions been realized correctly?
VPN
Virtual Private Network (logical connection for secure transmission of data via internet)
V&V state
state for verification, for validation and for release of an application; The current V&V state of an
application can be recorded in Safety V&V.
--- END OF DOCUMENT ---

DC0-117-2.04, Edition 04.2015

SIC RTUs Safety ENG PDF

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

SIC RTUs Safety ENG PDF

Uploaded by

Copyright:

Available Formats

Preface, Table of Contents

Principles of Functional Safety 1

This document is a translation of the original document

Subject to change without prior notice.

Siemens AG Order No.: DC0-117-2.04

Purpose of this manual

· SICAM TOOLBOX II .......... (V5.10 Hotfix 02 and higher)

· Manuals that are referenced are written in italics

SICAM RTUs, SAFETY 3

Document name Item number

SICAM AK System Description MC2-021-2

SICAM TM CP-6014/CPCX65 System Element Datasheet MC6-033-2

Common Functions Peripheral Elementes according to IEC 60870-5-101/104 DC0-011-2

SICAM TOOLBOX II Online-Help

For more information, please contact our Customer Support Center:

Main training centers are:

Nuremberg, Germany (Head Office) Vienna, Austria

Schenectady, NY, USA Hebburn, United Kingdom

4 SICAM RTUs, SAFETY

· persons planning, developing, assembling and/or commissioning safety-related E/E/PE

SICAM RTUs, SAFETY 5

1. Switch off electricity all-pole and on all sides!

Requirements for the development process

6 SICAM RTUs, SAFETY

1 Principles of Functional Safety .................................................................................. 13

1.1 Introduction .................................................................................................... 14

2 Functional Safety with SICAM RTUs .......................................................................... 23

2.1 Introduction .................................................................................................... 24

3 Safety System Description ......................................................................................... 33

SICAM RTUs, SAFETY 7

4 Safety System Configuration ...................................................................................... 69

4.1 SICAM AK 3 with Electrically & Optically Coupled PE's................................... 70

8 SICAM RTUs, SAFETY

4.2 SICAM TM with Electrically and Optically Coupled PE's .................................. 71

5 Workflows for working with SICAM Safety ................................................................ 75

5.1 Introduction .................................................................................................... 76

SICAM RTUs, SAFETY 9

5.13.6 Delta Examination of the Application........................................................ 110

6 Operating Modes ....................................................................................................... 115

6.1 Safe Operation ............................................................................................. 116

7 Error Detection and Management............................................................................. 127

7.1 Introduction .................................................................................................. 128

10 SICAM RTUs, SAFETY

8 System Response Time ............................................................................................ 141

8.1 General ........................................................................................................ 142

9 Safety Parameters ..................................................................................................... 145

9.1 Safety SICAM RTUs Parameters .................................................................. 146

10 Technical Data........................................................................................................... 153

10.1 Total System ................................................................................................ 154

11 Guidelines for Programming .................................................................................... 161

11.1 General ........................................................................................................ 162

SICAM RTUs, SAFETY 11

11.6.2 Safety Data Types ................................................................................... 168

A Checklists .................................................................................................................. 177

A.1 Planning ....................................................................................................... 177

B Installation Declaration ............................................................................................. 183

C TÜV Certificate .......................................................................................................... 187

12 SICAM RTUs, SAFETY

1.1 Introduction .................................................................................................... 14

SICAM RTUs, SAFETY 13

14 SICAM RTUs, SAFETY

1.2 Legal Basis

SICAM RTUs, SAFETY 15