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 file deletion operations to recipe files

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 applied to the FB input IDRecipeFile. The ID is not within the valid value range. Recipe file cannot be deleted. The FB verifies every ID applied to the FB inputs.
As a result,

no file is deleted, and

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

The recipe file to be deleted does not exist. Recipe file cannot be deleted. As a result,

the Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

Multiple delete requests for the same recipe file by several instances of the RecipeDeleteFile function block. If the multiple requests are not within the same cycle: Access conflict as the file can only be deleted once. Multiple requests within the same cycle: All instances report the same result (e.g., success by switching Done to SAFETRUE).
Otherwise (several cycles): Only one FB instance deletes the file and switches its Done output to SAFETRUE.
For the other FB instances which are not successful, the following applies:

The Done output remains SAFEFALSE, and

the FB shows an error code at its DiagCode output.

Possible fault/invalid operation	Consequences to be avoided	Countermeasure by the FB
Invalid file ID applied to the FB input IDRecipeFile. The ID is not within the valid value range.	Recipe file cannot be deleted.	The FB verifies every ID applied to the FB inputs. As a result, no file is deleted, and the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
The recipe file to be deleted does not exist.	Recipe file cannot be deleted.	As a result, the Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.
Multiple delete requests for the same recipe file by several instances of the RecipeDeleteFile function block.	If the multiple requests are not within the same cycle: Access conflict as the file can only be deleted once.	Multiple requests within the same cycle: All instances report the same result (e.g., success by switching Done to SAFETRUE). Otherwise (several cycles): Only one FB instance deletes the file and switches its Done output to SAFETRUE. For the other FB instances which are not successful, the following applies: The Done output remains SAFEFALSE, and the FB shows an error code at its DiagCode output.

Simultaneous read and "file delete" operations within one cycle

If an already activated SF_RecipeRead instance cyclically reads recipe data from a data set and a SF_RecipeDeleteFile 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.

Simultaneous write and "file delete" operations within one cycle

If an already active SF_RecipeDeleteFile instance and a SF_RecipeWrite FB both send a request for the same recipe file within the same cycle, the newly written/modified recipe file is deleted in the next cycle. This means that the data written by the SF_RecipeWrite instance are no longer available.

If, however, these data are read and processed cyclically 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 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:

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.