This is the web edition of the original ‎⮫ AC500-S safety user manual, version 1.3.2. This web edition is provided for quick reference only. The original safety user manual must be used to meet functional safety application requirements.

1.

Verify that only safety signals are used for all safety functions.

2.

Verify that not only safety application project is loaded to the safety CPU but also the relevant non-safety application project is loaded to non-safety CPU.

Verify that programs are saved from RAM memory to the flash memory, i.e., "Create boot project" is done.

3.

Up to Automation Builder 2.2.x: Verify that F-Parameters for all safety I/Os and other F-Devices set in F-Parameter editor are the same as those listed in AC500-S Programming Tool: “Global Variables  PROFIsafe”.

⮫ “Configuration and programming”

Automation Builder 2.3.x (and higher): Verify that a valid SVT report is present for the application project.

4.

F-Host on safety CPU can handle more than one F_Source_Add, if required, e.g., for PROFIsafe master - master coupling of different network islands. Verify that no ambiguous F_Source_Add settings for various F-Devices were set for the given safety application.

Note:

The rule "F_Source_Add <> F_Dest_Add for the given F-Device" is automatically checked by Automation Builder.

5.

Validate iParameters. Two options are available:

A) Validate that all iParameters (input delay, channel configuration, etc.) for all safety I/Os and other F-Devices are correct with a given F_iPar_CRC value using appropriate functional validation tests for those parameters (contact ABB technical support for more details)

or

B) Use a special verification procedure defined in⮫ “Verification procedure for safe iParameter setting in AC500-S safety I/Os” to validate each iParameter and then carry out only functional safety validation tests of your application (no need to check each single iParameter value). You have to provide a report confirming that all iParameters were checked as described in⮫ “Verification procedure for safe iParameter setting in AC500-S safety I/Os”.

Make sure that all F_iPar_CRC are > 0.

6.

Verify that the safety programming guidelines were properly used in the safety application program.

⮫ “Safety programming guidelines”

7.

All signals from the non-safety user program on non-safety CPU, which are evaluated in the safety program on the safety CPU, have to be also included when the safety application program is printed out.

8.

Has a review of the safety application program been carried out by a person not involved in the program creation?

9.

Has the result of the safety application program review been documented and released (date/ signature)?

10.

Was a backup of the complete safety (see note below) and non-safety project created before loading programs on safety and non-safety CPUs?

11.

Verify using the menu item “Online  Check boot project in PLC” that offline safety project in AC500-S Programming Tool and the boot project on the safety CPU are identical (file name, change date, title, author, version, description and CRC).

12.

If floating-point operations are used, verify that rules presented in⮫ “Floating-point operations” are taken into account and do not lead to any unsafe states in the safety application program.

13.

Verify that POU SF_WDOG_TIME_SET is called once in the safety application program and the watchdog time is correctly selected.

14.

Verify that a password for the safety CPU is set to prevent an unauthorized access to its data.

15.

Verify that only authorized personnel has “Write” access for safety module parameter settings and programs in Automation Builder and AC500-S Programming Tool.

16.

Verify that correct value for power supply supervision using POU SF_MAX_POWER_DIP_SET was set to have a correct system behavior in case of under- or overvoltage.

17.

Verify that POU SF_SAFETY_MODE is correctly used in the safety application program to avoid unintended safety program execution in DEBUG (non-safety) mode.

18.

Verify that no profile version change, “Update Device...”, Export/Import, Copy/Paste and Archive related functions in Automation Builder were executed on safety modules after the project was validated.

If the functions mentioned above were used and this leads to a safety boot project with a new CRC, then a full functional testing of all parts of the safety application has to be performed. This test must be carried out with the machine in its final configuration including mechanical, electrical and electronic components, sensors, actuators, and software.

19.

Verify using library CRC, shown in AC500-S Programming Tool, that only certified safety libraries with correct CRCs (refer to⮫ “Overview”) are used in the given safety project to execute safety functions. All other user-defined libraries have to be separately validated by the end-user to qualify for the given safety application.

20.

Make sure that internal POUs from SafetyUtil_CoDeSys_AC500_V22.lib and internal actions from SafetyBase_PROFIsafe_LV210_AC500_V22.lib (or older versions) are not called by end-user program, which starts from PLC_PRG as the main root.

21.

Make sure that, in AC500-S Programming Tool, all three system events (“CallbackInit”, “CallbackReadInputs” and “CallbackWriteOutputs”) in “Resources  Task configuration  System Events” remain selected.

22.

If the flash memory content (SF_FLASH_READ and/or SF_FLASH_WRITE FBs are called in the safety application) is used in the safety application for safety functions, then appropriate flash memory content validation procedures (e.g., proper safety application CRC over stored safety data) shall be implemented to ensure safety application data integrity before flash memory data are used in safety functions.

23.

Note:

The byte order in PROFIsafe data types depends on the used PROFIsafe device endianness and selected AC500 CPU type. (AC500 V2 non-safety CPU supports big-endian. AC500 V3 non-safety CPU supports little-endian.)

24.

If you use cyclic non-safe data exchange, make sure that only safety functions with up to SIL 2 (IEC 61508 and IEC 62061) and PL d (ISO 13849-1) will be triggered if sending data using cyclic non-safe data exchange.

Note:

If cyclic non-safe data exchange is used to send or receive safety-critical data, then SIL 3 (IEC 61508 and IEC 62061) and PL e (ISO 13849-1) safety requirements will not be fulfilled for sent or received data (independently on application safety communication profile used), because only one microprocessor (no 1oo2 safety architecture in the background) on safety CPU handles the sending and receiving direction.

Contact ABB technical support on how to reach SIL 3 and PL e.

25.

If you use cyclic non-safe data exchange, verify that the variable names of cyclic non-safe data exchange which are created for the safety CPU do not start with "S_", "GS_", "IS_" or "OS_".

Reviewer(s):

Machine/Application <ID>:

Signature:

Date: