• Home
• Function/Function Block Reference
• Safety-Related Recipe Handling Function Blocks
• SF_RecipeWrite
• Fault avoidance

Fault avoidance

This topic contains the following sections:

• Validation
• Recognition of incorrect/invalid write operations/accesses to recipe files (data sets)
• Simultaneous write and "file delete" operations within one cycle
• Simultaneous write and "data set delete" operations within one cycle
• Plausibility and connection errors
• Sporadically switching or toggling signal levels or impermissible signals
• Machine/system start-up without a function test for safety-related equipment

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 write operations/accesses to recipe files (data sets)

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 written to the file.	The FB verifies every ID applied to the FB inputs. As a result, no data is written, and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The written recipe data set is falsified/corrupted in the RAM of the Safety PLC due to a soft error.	The recipe file contains invalid data which could lead to a malfunction of your safety application and cause hazardous situations.	The Safety PLC compares the CRC over the data to be written between its both (diverse) channels. As a result of any detected inconsistency, the recipe file is not written, and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The Safety PLC is switched off while the recipe file is being written.	The recipe file is not completed and contains incomplete data which could lead to a malfunction of your safety application and cause hazardous situations. Note If the Safety PLC is switched to the HALT state during the write operation, no error is caused. Once the FB operation has been triggered, it is completed in the background. Furthermore, the safety application is not executed in HALT state.	The Safety PLC verifies the file CRC and thus detects incomplete recipe files. As a result, the recipe file is considered as invalid, and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output. Delete the affected recipe file using the SF_RecipeDeleteFile FB.
Multiple simultaneous write operations of a recipe file data set by several SF_RecipeWrite FB instances.	If the Safety PLC gets several write requests to the same data set within one Safety PLC cycle, the data within the data set are overwritten in the RAM. The data may then be unexpected which could lead to a malfunction of your safety application and cause hazardous situations.	The data of the FB instance executed first is lost. The Safety PLC recognizes this data loss by verifying the checksum over the affected data set (DataSetCRC). As a result, the following applies for the "not last executed instance": the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output. Only the FB instance executed last switches its Done output to SAFETRUE.
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 recipe 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).

Simultaneous write and "file delete" operations within one cycle

If a SF_RecipeWrite instance is currently writing a recipe data set in the RAM and a SF_RecipeDeleteFile or SF_RecipeDeleteDataSet instance initiates a delete command within the same cycle for the same file/data set, the affected data is deleted in the RAM. Thus, the SF_RecipeWrite instance is interrupted and enters an error state which it shows at its DiagCode output. The SF_RecipeDeleteFile or SF_RecipeDeleteDataSet instance, however, completes its operation successfully.

If the affected (i.e., deleted) data set is cyclically read and processed in your safety application, this may lead to a malfunction of your safety application and cause hazardous situations.

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 write accesses to and the deletion of recipe data sets/files are appropriately coordinated in the safety application.

Simultaneous write and "data set delete" operations within one cycle

If a SF_RecipeWrite instance and a SF_RecipeDeleteDataSet instance are called within the same cycle for the same data set, the instance called last completes its operation successful. The instance called first is "overruled" by the second FB and reports an error as it cannot validate its values.
Example: First, an SF_RecipeWrite instance is called and writes its payload values into the data set. Afterwards, an SF_RecipeDeleteDataSet instance is triggered and overwrites the newly written data set with 0-values (thus completing its operation successfully).

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 write accesses to and the deletion of recipe data sets/files are appropriately coordinated in the safety 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:

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:

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

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:

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.