Checklist for configuration and wiring

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.

No.	Item to check	Fulfilled (yes / no)?	Comment
1.	Are all safety input and output signals correctly configured and are the output signals connected to physical output channels?
2.	Verify that safety CPU switch addresses 0xF0 ... 0xFF are not used for safety CPU identification (e.g., PROFIsafe addresses).
3.	Verify that special organizational procedures (e.g., limited access to the cabinet where safety CPU is located) on the end-customer site are defined to avoid unintended firmware and/or boot code update on the safety CPU using SD card.
4.	Verify that correct parameter settings of non-safety CPU are used for the given safety application.
5.	Verify that required safety function response time of your safety application can be satisfied with current AC500-S safety PLC settings and your SFRT calculation is done based on⮫ “Safety function response time”.
6.	Verify that none of safety output channels has a configuration with "Detection" parameter = OFF, which reduces safety diagnostics for such safety output channels. If such configuration is used, explain in the "Comment" section of this checklist your reasons and claim that the required SIL and PL application levels can be reached with such configuration.
7.	Verify that: Address setting is correct. Assignment of signal inputs is complete. Assignment of signal outputs is complete. Assignment of unused inputs is complete. All terminal blocks are plugged.
8.	Verify that correct firmware versions are used for dependent non-safety components. Contact ABB technical support if needed.
9.	Verify that only one safety CPU is attached to non-safety CPU. The use of more than one safety CPU on one non-safety CPU is not allowed.
10.	Verify that the correct safety boot project is loaded on the right AC500-S safety CPU, for example, using organizational procedures or fault exclusion (only one safety CPU is available in the machine). Examples of organizational procedures are: If engineering PC is used and there is more than one safety CPU, then make sure that only one and right safety CPU is reachable for engineering PC when the given safety boot project is transferred to the safety CPU. If SD card is used and there is more than one safety CPU, then clearly identify each safety CPU and SD card using a proper ID marking on stickers attached to each safety CPU and SD card. These ID markings on stickers shall provide a clearly readable unique identification of each object to establish clear rules for relations "SD card with given safety boot project - safety CPU".
11.	Verify that the following rules were correctly applied for safe CPU to CPU communication using SM560-S-FD-1 and SM560-S-FD-4 CPUs: In the same codename space, F_Dest_Add shall be unique (Fig.402). In the same codename space, F_Source_Add shall not be re-used in other F-Hosts. Inside the same F-Host, a re-use is allowed for several F-Host Drivers. In the same codename space, F_Dest_Add shall not be used as F_Source_Add and vice versa.
12.	If SM560-S-FD-1 or SM560-S-FD-4 is used, make sure that F-Submodules ("12 Byte In/Out (PROFIsafe V2.4)" / "8 Byte and 2 Int In/Out (PROFIsafe V2.4)" / "12 Byte In/Out (PROFIsafe V2.6)" / "123 Byte In/Out (PROFIsafe V2.6 )") are correctly connected to master systems.
13.	Verify that not only codenames but also F_Dest_Add are unique in PROFIsafe networks, if only F_Dest_Add is checked by the F-Device.
Reviewer(s): Machine/Application <ID>: Signature: Date: