Nonsafety-Relevant Programs (NonSafe PRGs)

With compiler and runtime version V3.5.4.0 and higher, PRGs can also contain nonsafety-relevant code in a Safety SIL2 application. By default, all PRGs contain safety-relevant code. This is indicated by the yellow block symbol next to the standard POU symbol.

Figure 7. Application with safety-relevant PRGs

If the above requirements are fulfilled for the compiler version and the runtime system version, then the PRG Properties dialog has a SIL2 Properties tab with the Safety-Relevant PRG where the Contains Safety-Relevant Code property of the PRGs can be deactivated. You click the Properties command in the context menu of a PRG to open the properties dialog.

If a PRG does not contain safety-relevant code, then it is indicated by the gray block symbol next to the standard POU symbol.

Figure 8. Device tree with a safety-relevant PRG and a nonsafety-relevant PRG

Notes for using nonsafety-relevant programs

The following notes explain the recommended way to use nonsafety-relevant programs. Note that the manual from the device manufacturer supplements this information.

General

Nonsafety-relevant PRGs are primarily used to execute individual nonsafety-relevant partial functions within a generally safety-critical application.
These nonsafety-relevant PRGs must not have any influence over the safety-relevant parts. Freedom from interference on safe data is done by means of a memory protection.
POUs must not be inserted below a nonsafety-relevant PRG (such as methods, actions).
Nonsafety-relevant PRGs must not be declared in the POU pool. Shared POUs should be managed in libraries.

Data access and call hierarchy

Local and global data

The location of local data from POUs depends on the type:

Function
Local variables are in the stack
FB instance
Local variables of an FB are located in the FB instance.

For global data, the following POU types can be observed:

GVL (as well as EVL)
Global variables (standard data types, FB instances, DUTs)
PRG
Global variables (standard data types, FB instances, DUTs)

The following table shows which data access is permitted in general:

Context \ Access Type	Safety-Relevant Data		Nonsafety-Relevant Data
	Read	Write	Read	Write
Safety-relevant code	OK	OK	OK	OK
Nonsafety relevant code	OK	Not permitted	OK	OK

Call hierarchy

The use of nonsafety-relevant PRGs (calls in or from these POUs) is subject to specific restrictions because unauthorized access can lead to the safe state of the PLC.

Table 3. Call hierarchy

Call from / Call to	Safe PRG	Function (Safe-usable)	Safe FB Instance	NonSafe PRG	Function (NonSafe-usable)	NonSafe FB Instance
Safe PRG	OK	OK	OK	Not OK	Not OK	Not OK
Function (Safe-usable)	OK	OK	OK	Not OK	Not OK	Not OK
Safe FB Instance	OK	OK	OK	Not OK	Not OK	Not OK
NonSafe PRG	Not OK	Not OK	Not OK	OK	OK	OK
Function (NonSafe-usable)	Not OK	Not OK	Not OK	OK	OK	OK
NonSafe FB Instance	Not OK	Not OK	Not OK	OK	OK	OK

An FB instance is generally considered safety-relevant. The exceptions are as follows:

The FB is instantiated in a NonSafe PRG.
The FB is instantiated in an EVL.
The FB instance is move by means of "attribute location".
The FB declaration is in a nonsafety-relevant library.

Example 6. Example 1

The TON from the standard library (Safe) is instantiated in a PRG (Safe).

Result: The TON instance is in safe memory.

Example 7. Example 2

The TON from the standard library (Safe) is instantiated in a NonSafe PRG.

Result: The TON instance is in nonsafe memory.

Example 8. Example 3

The PD from the Util library (NonSafe) is instantiated in a PRG (Safe).

Result: The PD instance is in nonsafe memory.

Important

Using a POU from a nonsafe library in a safe PRG is not allowed.

Example 9. Example 4

The PD from the Util library (NonSafe) is instantiated in a NonSafe PRG.

Result: The PD instance is in nonsafe memory.