CODESYS Safety SIL2 package must be installed. See Safety project prerequisites.

CODESYS (Application) Programming Guidelines (-H2) shall be followed

Context of the executed code and variables are important in a safety project.

Violating guidelines may lead to SIL2 extension errors (see Project Build below).

This guide describes how context is determined for variables and POUs.

Safety projects contain safety related and non-safety POUs.

See also Reviewing Project Structure for a list of generated components in a safety project.

Safety projects use safety and non-safety libraries.

Library type is determined by SIL2 boolean property (TRUE/FALSE).

SIL2 property is added to a library's Project information > Properties tab.

Non-safety libraries used in a safety project should also include SIL2 property as FALSE.

Non-safe library POUs shall be called only in non-safe application code.

In addition to Build output, safety projects also have Safety SIL2 Extension output messages.

SIL2 output is generated when application binary is built (Build > Generate Code).

Not all of the errors in SIL2 extension output prevent downloading application to a safety control unit but they may lead to a firmware safe state during execution. An application shall not have errors in SIL2 extension output.

The context (safety/non-safety) of a variable depends on where it is declared.

POU variables depend on POU context and global variables depend on GVL (global variable list) context.

A non-safety POU shall not write to a variable in safety memory.

By default, an application's global variables are defined to safety memory.

A global variable list can be set to non-safety by using the following attribute pragma above the VAR_GLOBAL definition: {attribute 'location':='16#800'}

Refer to Known issues for restrictions in non-safety usage.

A safety library should not use global variables. Global variables in a safety library are in safety context.

If a safety library POU is used from an application’s non-safety program (PRG), it may lead to context issues.

Using global constants is allowed since they are read-only.

SAFE type variables, e.g. SAFEBYTE or SAFEINT exist only for better readability; it only affects the appearance (drawing color) of the variable and has no effect on the used context. S_JoystickControl variable in the image below is a SAFEINT variable.

A safety project's application STRUCTs are considered as safety related (see also, function block section).

STRUCT variable instance can be declared in safety or non-safety memory.

Variables in application STRUCT shall only use basic data types or safety library data types.

Using a data type (STRUCT) from a non-safety library in a safety application's STRUCT will result in a SIL2 extension's error (see the image below).

CODESYS gives SIL2 extension an error if a non-safety POU declares a STRUCT variable instance and initializes STRUCT members in the declaration part of a POU (see the example below). Initialize STRUCT members in code implementation.

All non-safety code is executed from PLC_PRG.

All safety code is executed from S_PLC_PRG.

Application non-safety code is added to Main PRG.

Application safety code is added to S_Main PRG.

A safety POU shall not call non-safety POU.

All POUs implemented in non-safety libraries are considered as non-safety.

A library POU that is intended to be used from both safety and non-safety application programs (PRG) shall be implemented in a safety library. Function (FUN) or function block (FB) should be used as POU type in this case.

An application program (PRG) can be safety related or non-safety. By default, the application program (PRG) is created as safety related.

See also, CODESYS IDE below.

Methods and actions shall not be added to an application's non-safety programs (PRG) (CODESYS SIL2 restriction).

Implementing methods or actions to a non-safety program (PRG), then calling non-safety POU in it (e.g. non-safe library POU) will lead to a SIL2 context error.

Only the main implementation of a non-safety program (PRG) is considered as non-safety.

Function blocks implemented in a safety application or in a safety library can be instanced to safety and non-safety code. The context of an instance depends on the owner of the instance.

Refer also to Known issues.

An instance of a non-safety function block (implemented by a non-safety library) shall not be created to  safety application's POU. This will lead to a SIL2 compilation error.

Function blocks implemented in a safety application or in a safety library are considered as safety related. Safety function blocks shall not use any data types or function block (FB) instances from non-safety libraries. This will result in a SIL2 context error.

It is recommended to implement function blocks in a non-safety library (SIL2 property = FALSE), if non-safety functionality is required. In this case the function block (FB) cannot be used in safety programs (PRG).

Functions (FUN) implemented in a safety library or by a safety application can be called from safety and non-safety code. The context depends on the caller.

Functions implemented in a non-safety library shall not be called from a safety program (PRG).

It will lead to a SIL2 compilation error.

Safety programs (PRG) are indicated with yellow blocks next to the POU icon.

Non-safety programs (PRG) are indicated with grey blocks next to the POU icon.

The program context (safety/non-safety) can be changed via Properties > SIL2 Properties.

By default, an application program (PRG) is created as safety related (Safe PRG).

When a program (PRG) is set to non-safety in CODESYS IDE, the location attribute is automatically created to the program (PRG).

In Function Block Diagram (FBD) editor, POUs are colored with a yellow background when it has SAFE variable type as an output. This affects the appearance for better readability. See also Known issues.

In FBD editor, interface variables using SAFE type are colored with a yellow background. This affects the appearance for better readability.