Fault avoidance

This topic contains the following sections:

Validation

Only you, the user, machine builder or system integrator can be aware of all the conditions and factors realized in the design of your application for the machine. Therefore, only you can determine the automation equipment and the related safeties and interlocks which can be properly used, and validate such usage.

WARNING

Unintended machine operation

Validate the overall safety-related function and thoroughly test the application.

Recognition of incorrect/invalid recipe data read from a file (data set)

The function block as well as the Safety PLC implement several verification and validation measures to help prevent malfunctions of the FB (and thus of the entire safety application) or the use of invalid recipe data.

Possible fault/invalid operation Consequences to be avoided Countermeasure by the FB

Invalid file ID and/or data set ID applied to the FB inputs IDRecipeFile and/or IDRecipeDataSet. The IDs are not within the valid value range. Data cannot be read from the data set. The FB verifies every ID applied to the FB inputs.
As a result,

no data is read, and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The recipe file to be read (specified at the IDRecipeFile input) does not exist. Data cannot be read from the data set. As a result,

no data is read, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The recipe data set to be read is corrupted or damaged. Wrong recipe values could be read and the variables connected to the PayloadRead** (with ** = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations. The Safety PLC calculates CRCs over the file and the data sets and compares them with the values stored in the file. This way, corrupted/damaged files or data sets are detected.
These validations are done independently of the settings at the FB inputs CheckDataSetCRC and CheckFileCRC, i.e., they cannot be deactivated via these inputs.
If an inconsistency is detected,

the data is considered as invalid, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The recipe file to be read belongs to different safety application. Unsuitable recipe values could be read and the variables connected to the PayloadRead** (with ** = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations. The Safety PLC verifies the project CRC (provided that the validation is activated via the FB input CheckProjectCRC).
Background information on the ProjectCRC comparison

The comparison of the project CRC helps ensuring that the recipe file to be read has been written out of exactly the same application project (version).

The project checksum has been calculated in PLCnext Engineer when building the project and was then written into the project file.
The SF_RecipeWrite FB reads this checksum from the project file and writes it into the header of the recipe file.
If the CheckProjectCRC input is set to SAFETRUE, the SF_RecipeRead FB reads the ProjectCRC from the recipe file header and compares it with the ProjectCRC of the current project.

If an inconsistency is detected,

the read data is considered as invalid, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The flash memory card has been moved to a different device. This means that the recipe file to be read was intended to be used for a different Safety PLC and possibly a different safety application. Unsuitable recipe values could be read and the variables connected to the PayloadRead** (with ** = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations. The Safety PLC verifies the serial number of the target device and recognizes an unsuitable recipe file (provided that the validation is activated via the CheckSerialNumber input).
The comparison of the serial number helps ensuring that the recipe file to be read has been written to exactly the same target.
As a result,

the read data is considered as invalid, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The recipe file has been replaced with another one deliberately or by mistake. Unsuitable recipe values could be read and the variables connected to the PayloadRead** (with ** = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations. The Safety PLC verifies the CRCs over the file and data set and compares them with the values applied to the FB inputs DataSetCRC and FileCRC.
Furthermore, the ProjectCRC is validated.
Background information on the ProjectCRC comparison

The comparison of the project CRC helps ensuring that the recipe file to be read has been written out of exactly the same application project (version).

The project checksum has been calculated in PLCnext Engineer when building the project and was then written into the project file.
The SF_RecipeWrite FB reads this checksum from the project file and writes it into the header of the recipe file.
If the CheckProjectCRC input is set to SAFETRUE, the SF_RecipeRead FB reads the ProjectCRC from the recipe file header and compares it with the ProjectCRC of the current project.

These validations are done provided that they are activated via the FB inputs CheckDataSetCRC, CheckFileCRC and CheckProjectCRC.
Furthermore, the serial number of the Safety PLC is verified (provided that the validation is activated via the CheckSerialNumber input).
If an inconsistency is detected,

the read data is considered as invalid, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The data set has been overwritten in the meantime by a SF_RecipeWrite function block. Wrong recipe values could be read and the variables connected to the PayloadRead** (with ** = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations. The Safety PLC verifies the CRCs over the file and data set and compares them with the values applied to the FB inputs DataSetCRC and FileCRC (provided that the validations are activated via the FB inputs CheckDataSetCRC and CheckFileCRC).
If an inconsistency is detected,

the read data is considered as invalid, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

Due to a "soft error" a recipe data set has been falsified in the RAM of the Safety PLC. This corruption took place prior to writing the file to the file system in the flash memory. Wrong recipe values could be read and the variables connected to the PayloadRead** (with ** = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations. The Safety PLC performs a data validation by a cross comparison between its both (diverse) channels.
If an inconsistency is detected,

the read data is considered as invalid, and

the payload values (failsafe values) at the inputs FV_PayloadRead** are applied to the FB outputs PayloadRead** (with ** = 0 to 15), and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output, and

the Safety PLC switches to the defined safe state.

Simultaneous read and write operations within one Safety PLC cycle. If an already activated SF_RecipeRead instance cyclically reads recipe data from a data set in the Safety PLC RAM and the data set data is overwritten by a SF_RecipeWrite FB at the beginning of a cycle (before the read operation), the data read within this particular cycle would not be as expected. This could lead to a malfunction of your safety application and cause hazardous situations.
See the example of a signal sequence diagram for details. The Safety PLC locks a file in the RAM against reading as soon as its content has been modified. This lock is released once the data has been successfully written to the file system (in the flash memory) and validated.
As a result, the following applies to the SF_RecipeRead instance involved:

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The SF_RecipeWrite instance involved, however, is not affected by this and may be completed successfully (Done = SAFETRUE).

Possible fault/invalid operation	Consequences to be avoided	Countermeasure by the FB
Invalid file ID and/or data set ID applied to the FB inputs IDRecipeFile and/or IDRecipeDataSet. The IDs are not within the valid value range.	Data cannot be read from the data set.	The FB verifies every ID applied to the FB inputs. As a result, no data is read, and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The recipe file to be read (specified at the IDRecipeFile input) does not exist.	Data cannot be read from the data set.	As a result, no data is read, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The recipe data set to be read is corrupted or damaged.	Wrong recipe values could be read and the variables connected to the PayloadRead (with = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC calculates CRCs over the file and the data sets and compares them with the values stored in the file. This way, corrupted/damaged files or data sets are detected. These validations are done independently of the settings at the FB inputs CheckDataSetCRC and CheckFileCRC, i.e., they cannot be deactivated via these inputs. If an inconsistency is detected, the data is considered as invalid, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The recipe file to be read belongs to different safety application.	Unsuitable recipe values could be read and the variables connected to the PayloadRead (with = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC verifies the project CRC (provided that the validation is activated via the FB input CheckProjectCRC). Background information on the ProjectCRC comparison The comparison of the project CRC helps ensuring that the recipe file to be read has been written out of exactly the same application project (version). The project checksum has been calculated in PLCnext Engineer when building the project and was then written into the project file. The SF_RecipeWrite FB reads this checksum from the project file and writes it into the header of the recipe file. If the CheckProjectCRC input is set to SAFETRUE, the SF_RecipeRead FB reads the ProjectCRC from the recipe file header and compares it with the ProjectCRC of the current project. If an inconsistency is detected, the read data is considered as invalid, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The flash memory card has been moved to a different device. This means that the recipe file to be read was intended to be used for a different Safety PLC and possibly a different safety application.	Unsuitable recipe values could be read and the variables connected to the PayloadRead (with = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC verifies the serial number of the target device and recognizes an unsuitable recipe file (provided that the validation is activated via the CheckSerialNumber input). The comparison of the serial number helps ensuring that the recipe file to be read has been written to exactly the same target. As a result, the read data is considered as invalid, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The recipe file has been replaced with another one deliberately or by mistake.	Unsuitable recipe values could be read and the variables connected to the PayloadRead (with = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC verifies the CRCs over the file and data set and compares them with the values applied to the FB inputs DataSetCRC and FileCRC. Furthermore, the ProjectCRC is validated. Background information on the ProjectCRC comparison The comparison of the project CRC helps ensuring that the recipe file to be read has been written out of exactly the same application project (version). The project checksum has been calculated in PLCnext Engineer when building the project and was then written into the project file. The SF_RecipeWrite FB reads this checksum from the project file and writes it into the header of the recipe file. If the CheckProjectCRC input is set to SAFETRUE, the SF_RecipeRead FB reads the ProjectCRC from the recipe file header and compares it with the ProjectCRC of the current project. These validations are done provided that they are activated via the FB inputs CheckDataSetCRC, CheckFileCRC and CheckProjectCRC. Furthermore, the serial number of the Safety PLC is verified (provided that the validation is activated via the CheckSerialNumber input). If an inconsistency is detected, the read data is considered as invalid, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The data set has been overwritten in the meantime by a SF_RecipeWrite function block.	Wrong recipe values could be read and the variables connected to the PayloadRead (with = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC verifies the CRCs over the file and data set and compares them with the values applied to the FB inputs DataSetCRC and FileCRC (provided that the validations are activated via the FB inputs CheckDataSetCRC and CheckFileCRC). If an inconsistency is detected, the read data is considered as invalid, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
Due to a "soft error" a recipe data set has been falsified in the RAM of the Safety PLC. This corruption took place prior to writing the file to the file system in the flash memory.	Wrong recipe values could be read and the variables connected to the PayloadRead (with = 0 to 15) would get wrong values. These incorrect values could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC performs a data validation by a cross comparison between its both (diverse) channels. If an inconsistency is detected, the read data is considered as invalid, and the payload values (failsafe values) at the inputs FV_PayloadRead are applied to the FB outputs PayloadRead (with ** = 0 to 15), and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output, and the Safety PLC switches to the defined safe state.
Simultaneous read and write operations within one Safety PLC cycle.	If an already activated SF_RecipeRead instance cyclically reads recipe data from a data set in the Safety PLC RAM and the data set data is overwritten by a SF_RecipeWrite FB at the beginning of a cycle (before the read operation), the data read within this particular cycle would not be as expected. This could lead to a malfunction of your safety application and cause hazardous situations. See the example of a signal sequence diagram for details.	The Safety PLC locks a file in the RAM against reading as soon as its content has been modified. This lock is released once the data has been successfully written to the file system (in the flash memory) and validated. As a result, the following applies to the SF_RecipeRead instance involved: the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output. The SF_RecipeWrite instance involved, however, is not affected by this and may be completed successfully (Done = SAFETRUE).

Data validation (CRCs and serial number)

The Safety PLC can perform a validation of the data read from a recipe data set. These validations detect if recipe data have been read from...

a file which belongs to a different safety application project, or
a target system other than the one for which the recipe file was written.

Each time, recipe data is read from a file, the FB calculates CRCs over the read data set and file. The FB then performs the validation by...

calculating CRCs (over the read data set and file) and
comparing them with the DataSetCRC and FileCRC to be expected.
The expected DataSetCRC and FileCRC values have been output by the SF_RecipeWrite FB when writing the recipe file and must be applied to the corresponding CRC input of the SF_RecipeRead FB.
comparing the project checksum stored in the recipe file header with the project checksum of the current project.
Background information on the ProjectCRC comparison

The comparison of the project CRC helps ensuring that the recipe file to be read has been written out of exactly the same application project (version).

The project checksum has been calculated in PLCnext Engineer when building the project and was then written into the project file.
The SF_RecipeWrite FB reads this checksum from the project file and writes it into the header of the recipe file.
If the CheckProjectCRC input is set to SAFETRUE, the SF_RecipeRead FB reads the ProjectCRC from the recipe file header and compares it with the ProjectCRC of the current project.
comparing the serial number of the controller from which recipe data is to be read with the serial number of the target for which the recipe file was written.

Precondition for performing a data validation: The respective validation must be activated by applying a SAFETRUE at the corresponding FB input CheckDataSetCRC, CheckFileCRC, CheckProjectCRC, and CheckSerialNumber. It is possible to activate only one, several or all validation methods.

If activated, the data validation sequence is as follows:

Calculation of a CRC over the read data set and the file.
Comparison of the calculated data set CRC with the CRC applied to the DataSetCRC input.
Comparison of the calculated file CRC with the CRC applied to the FileCRC input.
Comparison of the project CRC.
Comparison of the serial number of the PLC from recipe is to be read with the value contained in the recipe file to be read.

Data is only considered to be valid and Done is only set to SAFETRUE if no inconsistency is detected in any of these comparisons.

Deactivation of data validation

The validations described in section "Data validation" can be activated or deactivated via the FB inputs CheckDataSetCRC, CheckFileCRC, CheckProjectCRC, and CheckSerialNumber.

If any or all of these validations is deactivated, the following hazard message must be observed.

WARNING

Non-conformance to safety function requirements

Make certain that appropriate procedures and measures (according to applicable sector standards) have been established to verify that the read recipe data set has not been modified or belongs to another safety application in case that the CRC validations are deactivated (SAFEFALSE value at the input(s) CheckDataSetCRC, CheckFileCRC, or CheckProjectCRC).

Include in your risk analysis the impact of reading wrong recipe data from a modified or wrong recipe file while the CRC validations are deactivated.

Validate the overall safety-related function with regard to possible impact of reading data from a modified or wrong recipe file while the CRC validations are deactivated.

Allowed multiple accesses of different FBs to the same recipe file

The following scenarios are not considered as faulty behavior. The safety application, however, should be validated with regard to the correct and intended logical behavior.

Multiple read accesses on the same file/data set by several instances of the SF_RecipeRead function block are possible and do not necessarily result in an error state. The file in the flash memory can only be accessed by one FB. Recipe data in the RAM, however, can be accessed by several FBs. Whether the read operation of an individual instance is successful depends on the successful final validation of the read values.
Simultaneous read and "delete" operations within one Safety PLC cycle.
If an already active SF_RecipeRead instance cyclically reads recipe data from a data set and a SF_RecipeDeleteFile instance requests the deletion of the same file at the beginning of a cycle (before the read operation), the following applies:
The SF_RecipeRead FB reads data that is already enabled for deletion and validates the data (indicated by Done = SAFETRUE). In the next cycle, the file is deleted and no longer available. Any further read access would lead to an error of the SF_RecipeRead FB.
This scenario is not considered as a fault and is therefore not prevented by the Safety PLC. It is your responsibility as an application developer to ensure that read accesses to and the deletion of recipe files are appropriately coordinated in the safety application.

Correct connection and further processing of read recipe values

The values applied by the FB at its outputs PayloadRead** (with ** = 0 to 15) are usually connected to the inputs of further safety-related function blocks or to safety-related variables which are further processed in the safety application. This way, these values may influence the behavior of the safety function. Logically incorrect connections cannot be detected by the programming system of the Safety PLC. It is therefore the sole responsibility of the developer of the safety application to ensure that the outputs PayloadRead** are correctly connected and processed. Observe the following hazard message.

WARNING

Non-conformance to safety function requirements

Verify that the outputs PayloadRead** (with ** = 0 to 15) of the function block are connected to the correct variables/block inputs and are further processed in accordance with your risk analysis.

Validate the overall safety-related function with regard to the connection of the outputs PayloadRead** (with ** = 0 to 15) and thoroughly test the application.

Up-to-dateness and correctness of the recipe values

The values contained in a recipe data set must be up-to-date and suitable for the correct function of your safety application. Incorrect or outdated values cannot be detected by the FB or the Safety PLC. Observe the following hazard message.

WARNING

Non-conformance to safety function requirements

Verify that the values contained in the recipe data set to be read are up-to-date and correspond to the values delivered by your risk analysis.

Be sure that your risk analysis includes an evaluation for outdated or incorrect values read from the recipe data set.

Validate the overall safety-related function with regard to the up-to-dateness/correctness of the read values and thoroughly test the application.

Plausibility and connection errors

Plausibility errors are errors which occur, for example, when a range of values is exceeded or an impermissible connection is made. Such errors are detected and reported either by the function block itself or while the project is being compiled. However, this is not always possible in the case of connection errors.

This means that it is not possible, for example, to automatically verify whether:

Values or constants within the range of validity at inputs are, in fact, incorrect for the safety-related function executed.
Inputs and/or outputs are incorrectly connected or are not connected when they should be.

WARNING

Unintended machine operation

Validate the signals, formulas, variables or constants connected to the input and output formal parameters of the safety-related function block and thoroughly test the application.

Sporadically switching or toggling signal levels or impermissible signals

If no additional fault avoidance measures are taken, signal levels which switch or toggle sporadically at the state-controlled inputs may cause the signal to trigger a potentially undesirable corresponding action.

Impermissible signals at inputs can lead to an unintended start, prevent a requested action from being executed or cause an error.

These signals may be caused by:

Programming errors in the application program (user errors).
Cross circuit, short circuit, and cable break (user errors, wiring errors).

To prevent this, the following measures can be taken, depending on the safety-related function:

Using options for cross-circuit detection.
Suitable cabling.
Verifying the safety-related code in the Code Editor followed by validation of all safety-related networks.

The measures listed above can also be taken in combination in order to help prevent cascading or otherwise difficult to detect errors.

Machine/system start-up without a function test for safety-related equipment

Inoperable or error producing safety-related equipment can only be detected by testing whether it is functioning correctly. The function block does not support function testing.

Possible causes of inoperable or error producing safety-related equipment are:

Inoperable devices (hardware errors)
Cross circuit, short circuit, and cable break (user errors, wiring errors)

WARNING

Unintended machine operation

Validate the safety-related equipment by performing function tests.

Prior to performing function tests, make certain that appropriate procedures and measures (according to applicable sector standards) have been established to help avoid hazardous situations if the safety logic operates in ways you did not intend.

Do not enter the zone of operation while the machine is operating.

Ensure that no other persons can access the zone of operation while the machine is operating.

Observe the regulations given by relevant sector standards while the machine is running in any other operating mode than "operational".

Use appropriate safety interlocks where personnel and/or equipment hazards exist.