General Programming Guidelines; Safety-Oriented And Non-Safety-Oriented Parts Of The Application - ABB AC500-S Safety User Manual

CoDeSys Safety programming guidelines > Safety-oriented and non-safety-oriented parts of the application

4.4.4 General programming guidelines

In addition to language-specific guidelines, errors should be avoided through compliance with additional gen-
eral guidelines. These guidelines are listed here in no particular order:
n Few states
States in the form of variables that retain their value beyond a control cycle hamper the testability of an
application. This can be avoided with the following measures:
– Avoidance of states wherever possible
– A state variable should only be described once per cycle. This facilitates tracing of errors if a state
has an invalid value.
– If a state consists of several variables it should be encapsulated in a function block. State transitions
should only be affected by calling the block.
n No warnings
A safety-oriented application must not generate compiler warnings!
n Limited number of rows (500) per block
In the interest of transparency, a block should have no more than 500 rows.
Limited number of characters per row (150)
n
In the interest of transparency, a row should have no more than 150 characters
n No reuse of variables
Each variable should only be used for one purpose. Application in another context, even if the previous
purpose is no longer important, involves a significant fault potential, particularly for modifications.
Variables as local as necessary
n
Variables that are only described in one block must be declared locally. The only exception is variables
that are linked with addresses. These should be declared globally in order to avoid multiple assignments.
n Only one access to output
As for states, outputs should only be described at one point in the program.
n No access to global variables from functions and function blocks
A function should have no side effects, a function block should only change the state of its own instance.
Functions and function blocks should therefore not access global variables.

4.4.5 Safety-oriented and non-safety-oriented parts of the application

For very complex applications, it is advisable to transfer all safety-oriented application parts to a separate
control system. If this is not possible, the application parts should be separated through the following meas-
ures:
Blocks (programs, function blocks and functions) are either safety-oriented or not. All safety-oriented
n
blocks should be identified through a prefix (e.g., "S_").
n Calls of non-safety-oriented blocks in safety-oriented blocks are not permitted. This must be checked
with the "Show project call tree" function.
n Calls of safety-oriented blocks in non-safety-oriented blocks are limited to standard functions. This must
be checked with the "Show project call tree" function.
n Global variables are either safety-oriented or not. All safety-oriented variables should be identified
through a prefix (e.g., "S_"). All safety-oriented variables are defined in separate variable lists that are
also identified through a prefix.
n Write access to safety-oriented variables from non-safety-oriented blocks is not permitted. This must be
checked with the "Show project cross-reference list" function.
n Write access to non-safety-oriented variables from safety-oriented blocks is not permitted. This must be
checked with the "Show project cross-reference list" function.
30.03.2017
Configuration and programming
AC500-S 221