Siemens SIMATIC S7-1200 Instruction Manual

Safety Programming
Guideline for SIMATIC
S7-1200/1500
SIMATIC Safety Integrated
https://support.industry.siemens.com/cs/ww/en/view/109750255
Siemens
Industry
Online
Support

Warranty and Liability
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
2
Siemens AG 2017 All rights reserved
Warranty and Liability
Note
The Application Examples are not binding and do not claim to be complete regarding the
circuits shown, equipping and any eventuality. The Application Examples do not represent
customer-specific solutions. They are only intended to provide support for typical
applications. You are responsible for ensuring that the described products are used
correctly. These Application Examples do not relieve you of the responsibility to use safe
practices in application, installation, operation and maintenance. When using these
Application Examples, you recognize that we cannot be made liable for any
damage/claims beyond the liability clause described. We reserve the right to make
changes to these Application Examples at any time without prior notice.
If there are any deviations between the recommendations provided in these Application
Examples and other Siemens publications –e.g. Catalogs –the contents of the other
documents have priority.
We do not accept any liability for the information contained in this document.
Any claims against us –based on whatever legal reason –resulting from the use of
the examples, information, programs, engineering and performance data etc.,
described in this Application Example shall be excluded. Such an exclusion shall
not apply in the case of mandatory liability, e.g. under the German Product Liability
Act (“Produkthaftungsgesetz”), in case of intent, gross negligence, or injury of life,
body or health, guarantee for the quality of a product, fraudulent concealment of a
deficiency or breach of a condition which goes to the root of the contract
(“wesentliche Vertragspflichten”). The damages for a breach of a substantial
contractual obligation are, however, limited to the foreseeable damage, typical for
the type of contract, except in the event of intent or gross negligence or injury to
life, body or health. The above provisions do not imply a change of the burden of
proof to your detriment.
Any form of duplication or distribution of these Application Examples or excerpts
hereof is prohibited without the expressed consent of the Siemens AG.
Security
informa-
tion
Siemens provides products and solutions with industrial security functions that support the
secure operation of plants, systems, machines and networks.
In order to protect plants, systems, machines and networks against cyber threats, it is
necessary to implement –and continuously maintain –a holistic, state-of-the-art industrial
security concept. Siemens’ products and solutions only form one element of such a
concept.
Customer is responsible to prevent unauthorized access to its plants, systems, machines
and networks. Systems, machines and components should only be connected to the
enterprise network or the internet if and to the extent necessary and with appropriate
security measures (e.g. use of firewalls and network segmentation) in place.
Additionally, Siemens’ guidance on appropriate security measures should be taken into
account. For more information about industrial security, please visit
http://www.siemens.com/industrialsecurity.
Siemens’ products and solutions undergo continuous development to make them more
secure. Siemens strongly recommends to apply product updates as soon as available and
to always use the latest product versions. Use of product versions that are no longer
supported, and failure to apply latest updates may increase customer’s exposure to cyber
threats.
To stay informed about product updates, subscribe to the Siemens Industrial Security
RSS Feed under http://www.siemens.com/industrialsecurity.

Table of Contents
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
3
Siemens AG 2017 All rights reserved
Table of Contents
Warranty and Liability ................................................................................................. 2
1Introduction........................................................................................................ 4
2Configuring Fail-Safe Controllers.................................................................... 6
2.1 Selecting the suitable F-CPU............................................................... 6
2.2 PROFIsafe address types.................................................................... 8
2.3 Protecting the F-CPU against unauthorized access ............................ 9
2.4 F-change history................................................................................. 11
2.5 Consistently uploading F-CPUs ......................................................... 12
2.6 Know-how protection.......................................................................... 13
3Methods for Safety Programming.................................................................. 14
3.1 Program structures............................................................................. 14
3.1.1 Defining a program structure.............................................................. 14
3.1.2 Call levels of F-FBs/F-FCs................................................................. 16
3.1.3 Call sequence of the blocks in the Main Safety ................................. 16
3.1.4 F-suitable PLC data type.................................................................... 18
3.2 Block information and comments....................................................... 20
3.3 Functional identifiers of variables....................................................... 21
3.4 True & False....................................................................................... 22
3.5 Standardizing blocks.......................................................................... 23
3.5.1Standardizing sensor evaluation........................................................ 23
3.5.2 Standardizing actuator control ........................................................... 25
3.6 Programming logic operations ........................................................... 26
3.7 Programming mode-dependent safety functions ............................... 26
3.8 Connecting global data....................................................................... 27
3.9 Data exchange between standard user program and safety
program.............................................................................................. 28
3.9.1 Reading diagnostic and message information from the safety
program.............................................................................................. 29
3.9.2 Transferring operational information to the safety program............... 30
3.9.3 Using non-safe inputs in the safety program...................................... 30
3.9.4 Transferring HMI signals to the safety program................................. 31
3.10 Resetting functional switching............................................................ 33
3.11 Reintegrating fail-safe I/O modules/channels .................................... 34
3.11.1 Evaluating passivated modules/channels.......................................... 34
3.11.2 Automatic reintegration ...................................................................... 36
3.11.3 Manual reintegration........................................................................... 37
4Optimizing Safety Programs .......................................................................... 38
4.1 Optimizing the compilation duration and runtime............................... 38
4.1.1 Jumps in the safety program.............................................................. 39
4.1.2 Timer blocks....................................................................................... 41
4.1.3 Multi-instances ................................................................................... 41
4.2 Avoiding data corruption..................................................................... 43
5Glossary ........................................................................................................... 45
6Appendix .......................................................................................................... 47
6.1 Service and Support........................................................................... 47
6.2 Links and literature............................................................................. 48
6.3 Change documentation...................................................................... 48

1 Introduction
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
4
Siemens AG 2017 All rights reserved
1 Introduction
The new controller generation SIMATIC S7-1200 and S7-1500 has an up-to-date
system architecture and, together with TIA Portal, offers new and efficient
programming and configuration options.
If the programming is sloppy, the many options provided by STEP 7 can also
produce negative results:
CPU stops
Long compilation processes
Additional, comprehensive acceptance testing
This document provides you with many recommendations and notes for the optimal
configuration and programming of S7-1200/1500 controllers. This helps you create
standardized and optimal programming of your automation solutions.
The examples described in this document can be universally used on the S7-1200
and S7-1500 controllers.
Advantages
Following the recommendations given in this document provides you with many
advantages:
Reusability of program parts
Easier acceptance (code review, error detection and correction)
More flexibility in terms of program changes
Reduction of programming errors
Increased plant availability by avoiding CPU stops
Easier readability for third parties
Reduced runtime of the safety program
Note
Not all the recommendations provided in this document can be applied at the
same time. In these cases, it is up to you as the user to decide on the
prioritization of the recommendations (e.g., standardization or runtime
optimization of the safety program).

1 Introduction
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
5
Siemens AG 2017 All rights reserved
Programming guideline and styleguide
The recommendations given in the programming guideline and the programming
styleguide always apply to programming safety programs.
Programming Guideline for SIMATIC S7-1200/1500:
https://support.industry.siemens.com/cs/ww/en/view/90885040
Programming Styleguide for SIMATIC S7-1200/1500:
https://support.industry.siemens.com/cs/ww/en/view/109478084
This document is a supplement to the documents above and deals with special
aspects of programming safety programs with STEP 7.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
6
Siemens AG 2017 All rights reserved
2 Configuring Fail-Safe Controllers
2.1 Selecting the suitable F-CPU
Selecting the F-CPU depends on the following factors:
Runtime of the safety program
PROFIsafe communication time
Response time of the safety function
Number of required inputs and outputs
Number of connected I/O devices
Estimate of the response time
If you already have a rough idea of the automation system you want to use, you
can estimate the response time of your safety program using the SIMATIC STEP 7
Reaction Time Table or go through various scenarios to select the suitable F-CPU:
https://support.industry.siemens.com/cs/ww/en/view/93839056
Figure 2-1: Reaction time wizard of the SIMATIC STEP 7 Reaction Time Table
Influence of the safety program's cycle time on the standard user program
A long cycle time of the safety program slows down the response time of your
safety functions, but allows more time for processing the standard user program.
A short cycle time of the safety program increases the response time of your safety
functions, but allows less time for processing the standard user program.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
7
Siemens AG 2017 All rights reserved
The following figure shows the influence of the safety program's cycle time on the
time that is available for processing the standard user program.
Figure 2-2: Influence of the safety program's cycle time on the standard user program
Note
Please note that higher-priority organization blocks (e.g., cyclic interrupt OBs or
motion control OBs) can interrupt the safety program in the same way as shown
in Figure 2-2.
To make sure that the safety program cannot be interrupted, you can customize
the priorities in the properties of the appropriate OBs.
NOTICE
The cycle time must be longer than the execution duration of the safety program.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
8
Siemens AG 2017 All rights reserved
2.2 PROFIsafe address types
The PROFIsafe address is used to uniquely address F-I/O and protect standard
addressing mechanisms such as IP addresses. Uniqueness is defined differently
for F-I/O of PROFIsafe address type 1 and F-I/O of PROFIsafe address type 2.
Table 2-1: Differences between the PROFIsafe address types
PROFIsafe address type 1
PROFIsafe address type 2
The uniqueness of the PROFIsafe
address is ensured only by the F-
destination address.
The F-destination address must be
unique throughout the network and the
CPU.
In the safety summary, each F-
destination address has to be checked
for network- and CPU-wide uniqueness
by making sure that the F-destination
address ranges of all F-CPUs do not
overlap.
The F-destination address and the F-
source address are included in the
safety program's CRC.
The uniqueness of the PROFIsafe
address is ensured by combining the F-
source address and the F-destination
address.
The F-destination address must be
unique throughout the CPU and differ
from all other F-destination addresses
of PROFIsafe address type 1 in the
same network.
The F-destination address used for the
F-I/O of an F-CPU must be unique
throughout the network.
The F-destination address and the F-
source address are included in the
safety program's CRC.
You must ensure that each PROFIsafe address is unique.
The ever increasing networking of plants and plant sections –especially if
configured separately –makes accurate planning of the PROFIsafe address
assignment all the more necessary.
The use of F-I/O of PROFIsafe address type 2 makes handling PROFIsafe
addresses easier. With mixed configurations or pure address type 1 configurations,
however, one has to be more careful.
Recommendation
Already at the outset of the project, look at possible communication
relationships and network topologies. Consult with the parties involved to
derive measures for assigning PROFIsafe addresses.
Assign separate address ranges to PROFIsafe address types 1 and 2:
–Assign a low number range to F-I/O of PROFIsafe address type 11).
–Assign a high number range to F-I/O of PROFIsafe address type 2.
Always define unique F-source addresses for all F-CPUs. This makes both
working across projects and later extensions easier.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
9
Siemens AG 2017 All rights reserved
1) You can define the allowed range for F-destination addresses of PROFIsafe
address type 1 in the CPU properties.
Figure 2-3: Defining the address range for F-destination addresses
Additional information
For more information about PPROFIsafe address types, visit Siemens Industry
Online Support:
What is the difference between the PROFIsafe address types 1 and 2 in relation to
the uniqueness of the PROFIsafe address?
https://support.industry.siemens.com/cs/ww/en/view/109479905
How do you assign PROFIsafe addresses so that they are unique network-wide
and CPU-wide?
https://support.industry.siemens.com/cs/ww/en/view/109740240
2.3 Protecting the F-CPU against unauthorized access
To prevent unauthorized modifications or tampering with a safety program, you
must implement appropriate access protection.
This can be done, for example, through organizational measures (such as locking
the control cabinet).
However, easier and more efficient access protection can be achieved by
assigning passwords.
You can set up separate access protection mechanisms for the safety program and
the F-CPU.
Access protection for the safety program
Access protection for the safety program makes sure that the F-program is not
modified by unauthorized persons.
You define the password for access protection for the safety program in Safety
Administration in TIA Portal.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
10
Siemens AG 2017 All rights reserved
Figure 2-4: Defining the password for the safety program
Once you have logged in with the password for the safety program, you can
remove the access rights to the safety program as follows:
Log out of Safety Administration
In the menu bar, "Online > Delete access rights"
Close TIA Portal
Note
Collaboration of programmers with and without rights for the user program
Changes to standard DBs that are read/write accessed by the safety program
require a recompilation of the safety program. These standard DBs are not
subject to the access permission for the safety program. Therefore, data
exchange between the F-program and the standard program requires a defined
interface that the programmer of the standard user program does not have to
change during his work.
For more information about this data exchange, please refer to Chapter 3.9.
Access protection for the F-CPU
Access protection for the F-CPU ensures that only authorized persons can
download a safety program to the device or disable safety mode.
The password for the F-CPU is defined in the CPU properties.
Figure 2-5: Defining the password for the F-CPU
Access protection applies only to the appropriate F-CPU. This password is also
used for identification of the F-CPU and must therefore be unique throughout the
network.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
11
Siemens AG 2017 All rights reserved
2.4 F-change history
F-change history acts like the standard user program's change history. In the
project tree, "Common data > Logs", one F-change history is created for each
F-CPU.
F-change history logs the following:
F-collective signature
User name
Compile time stamp
Download of the safety program with time stamp
Compiled F-blocks with signature and time stamp
Figure 2-6: F-change history
Recommendation
Activate change history when you start configuring or at the latest when you have
defined the final project-specific CPU name as the change history is linked to the
CPU name.
Figure 2-7: Activating F-change history

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
12
Siemens AG 2017 All rights reserved
Advantages
Ensures that the last change was loaded by comparing the online and offline
status of the CRC.
Which user changed or downloaded the safety program can be tracked in
multi-user projects.
Matching of online and offline status without an online connection between
CPU and PG/PC.
NOTICE
F-change history must not be used to detect changes in the safety program or
when accepting changes in the F-I/O configuration.
2.5 Consistently uploading F-CPUs
TIA Portal V14 SP1 and higher allows you to consistently upload fail-safe SIMATIC
S7-1500 CPUs from the automation system to TIA Portal.
Recommendation
An upload from the automation system is only possible if the project has been
released for it.
When you start configuring, check the "Consistent upload" check box in Safety
Administration in TIA Portal.
Figure 2-8: Enabling "Consistent upload"
Advantages
As there is no complex "offline" project management, you can avoid errors and
further reduce the service effort.

2 Configuring Fail-Safe Controllers
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
13
Siemens AG 2017 All rights reserved
2.6 Know-how protection
STEP 7 Safety V14 or higher allows you to activate know-how protection for fail-
safe blocks (FCs and FBs).
Know-how protection protects specific program parts against access by
unauthorized persons, regardless of the F-CPU's and the safety program's access
protection. The contents of an FC or FB cannot be viewed or modified without a
password.
Recommendation
During the project phase, determine to what extent it makes sense to protect the
blocks of a safety program against third-party access.
Advantages
Protects your know-how across contents of program parts.
Accepted blocks cannot be modified.
Additional information
The following documentation provides instructions for using know-how protection
for different scenarios:
https://support.industry.siemens.com/cs/ww/en/view/109742314

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
14
Siemens AG 2017 All rights reserved
3 Methods for Safety Programming
3.1 Program structures
3.1.1 Defining a program structure
Recommendation
Modularly divide the program code, e.g.,
–into subparts for detecting, evaluating, reacting or
–plant sections.
In the preliminary stages, create a specification for each module (based on the
risk assessment requirements).
Avoid complex signal paths.
Advantages
Minimizes complexity.
Reduces programming errors.
Allows the program code to be analyzed/tested without running the program
(e.g., code review or PLCSIM).
Easily expandable. Simplifies renewed acceptance.
Reuse of program parts without renewed acceptance.
Allows advance testing and acceptance of finished program parts.
Example
The following figure shows a safety application that is divided into three machine
areas (safety zones).
As some of the sensor signals are interconnected across areas (e.g., emergency
stop functions that act globally), they are grouped into a "Sensors" FB (they could
also be split up into physical or logical areas). The respective sensors are
evaluated using standardized function blocks (e.g., "GuardDoor").
The Mobile Panels' blocks are also called here.
Separate logic and actuator FBs are created for each machine area. The actuators
are controlled using standardized function blocks (e.g., "ContactorControl").

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
15
Siemens AG 2017 All rights reserved
Figure 3-1: Example of a program structure
Note
The structure shown here is an example. Depending on the size and complexity
of the safety program, you can also choose a different structure. In smaller
applications, it would, for example, also be possible to implement the logic and
actuator control in a shared function block.

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
16
Siemens AG 2017 All rights reserved
3.1.2 Call levels of F-FBs/F-FCs
For standard user programs, the number of call levels is limited depending on the
CPU. For safety programs, you can use a maximum of eight call levels. A warning
appears when this limit is exceeded and an error message is displayed for pure FC
and multi-instance call chains.
System instructions ("ESTOP1", "SF_DOOR", etc.) are not included in the number
of call levels.
Note
On the system side, functions are mapped as FBs with a multi-instance call in
the protection program; this is the reason why an error message is also
displayed for FC call chains with more than eight call levels.
The program structure in Figure 3-1 shows one way of keeping the call levels
relatively flat so that the safety program remains within the limit specified here.
3.1.3 Call sequence of the blocks in the Main Safety
Recommendation
Within the Main Safety, call blocks in the following sequence:
1. Receive blocks from other CPUs (F-CPU-F-CPU communication)
2. Error acknowledgment/reintegration of F-modules/F-channels
3. Evaluation block of the sensors
4. Operating mode evaluation
5. Logic operations, calculations, evaluations, etc.
6. Control blocks for safe actuators
7. Send blocks to other CPUs (F-CPU-F-CPU communication)

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
17
Siemens AG 2017 All rights reserved
Figure 3-2: Call sequence in the Main Safety
Advantages
The CPU always uses the latest values
Facilitates orientation in the Main Safety

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
18
Siemens AG 2017 All rights reserved
3.1.4 F-suitable PLC data type
For safety programs, too, it is possible to optimally structure data using PLC data
types.
F-suitable PLC data types have the following features:
F-suitable PLC data types are declared and used in the same way as PLC data
types.
All data types that are allowed in the safety program can be used in F-suitable
PLC data types.
Nesting F-suitable PLC data types within other F-suitable PLC data types is not
supported.
F-suitable PLC data types can be used both in the safety program and in the
standard user program.
Recommendation
Create F-suitable PLC data types to structure data also in the safety program.
Use F-suitable PLC data types to transfer large numbers of variables to blocks.
Use F-suitable PLC data types for access to I/O ranges.
In this context, follow the below rules:
–The structure of the tags of the F-suitable PLC data type must match the
channel structure of the F-I/O.
–Example of an F-suitable PLC data type for an F-I/O with 8 channels:
8 BOOL variables (channel value) or
16 BOOL variables (channel value + value status)
–Access to F-I/O is only allowed for activated channels. When configuring a
1oo2 evaluation, the higher-level channel is always deactivated.
Advantages
A change in a PLC data type is automatically updated in all points of use in the
user program.

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
19
Siemens AG 2017 All rights reserved
Example
Figure 3-3: Access to I/O ranges with F-suitable PLC data types
F-I/O
F-suitable PLC data type
PLC tag

3 Methods for Safety Programming
Safety Programming Guideline
Entry ID: 109750255, V1.0, 10/2017
20
Siemens AG 2017 All rights reserved
3.2 Block information and comments
General
In SIMATIC Safety, the Function Block Diagram (FBD) and Ladder Diagram (LAD)
programming languages are available to you. Both languages provide the option to
store block and network comments.
Comments have no influence on the signature of F-FBs/F-FCs and can therefore
also be edited after acceptance.
Recommendation
In the block comment of your block, enter formal information about the block with
the aid of the following template.
If you implement diagnostic functions relevant to the PL / SILCL of another
subsystem (Detect or Evaluate) in an F-FB, include normative parameters such as
PL / SILCL and category (according to ISO 13849-1), DC measures, CCF
measures, etc. in the block comment.
After successful acceptance of the block, also include the signature in the block
comment. This makes it easier to track functional changes of the block.
//============================================================================
// Company
//----------------------------------------------------------------------------
// Library: (that the source is dedicated to)
// Tested with: (test system with FW version)
// Engineering: TIA Portal (SW version)
// Restrictions: (OB types, etc.)
// Requirements: (hardware, technological package, memory needed, etc.)
// Functionality: (that is implemented in the block)
//----------------------------------------------------------------------------
// Reference to Safety Requirement Specification:
// Safety related information: (SIL/PL (Cat.), DC, methods against CFF for connected
subsystems)
//----------------------------------------------------------------------------
// Change log table:
// Version Date Signature Expert in charge Changes applied
// 01.00.00 (dd.mm.yyyy) (Block CRC) (Name of expert) First released version
//============================================================================