GuardLogix Controller Systems

Transcription

1 GuardLogix Controller Systems (Catalog Numbers 1756-L61S, 1756-L62S, 1756-LSP) Safety Reference Manual

2 Important User Information Solid state equipment has operational characteristics differing from those of electromechanical equipment. Safety Guidelines for the Application, Installation and Maintenance of Solid State Controls (Publication SGI-1.1 available from your local Rockwell Automation sales office or online at describes some important differences between solid state equipment and hard-wired electromechanical devices. Because of this difference, and also because of the wide variety of uses for solid state equipment, all persons responsible for applying this equipment must satisfy themselves that each intended application of this equipment is acceptable. In no event will Rockwell Automation, Inc. be responsible or liable for indirect or consequential damages resulting from the use or application of this equipment. The examples and diagrams in this manual are included solely for illustrative purposes. Because of the many variables and requirements associated with any particular installation, Rockwell Automation, Inc. cannot assume responsibility or liability for actual use based on the examples and diagrams. No patent liability is assumed by Rockwell Automation, Inc. with respect to use of information, circuits, equipment, or software described in this manual. Reproduction of the contents of this manual, in whole or in part, without written permission of Rockwell Automation, Inc. is prohibited. Throughout this manual, when necessary we use notes to make you aware of safety considerations. WARNING Identifies information about practices or circumstances that can cause an explosion in a hazardous environment, which may lead to personal injury or death, property damage, or economic loss. IMPORTANT Identifies information that is critical for successful application and understanding of the product. ATTENTION Identifies information about practices or circumstances that can lead to personal injury or death, property damage, or economic loss. Attentions help you: identify a hazard avoid a hazard recognize the consequence Allen-Bradley, ControlLogix, GuardLogix, RSLogix, RSNetWorx for DeviceNet, and RSLinx are trademarks of Rockwell Automation, Inc. DeviceNet is a trademark of the Open DeviceNet Vendor Association. Trademarks not belonging to Rockwell Automation are the property of their respective holders.

3 Summary of Changes The information below summarizes the changes to this manual since the last publication. To help you find new and updated information in this release of the manual, we have included change bars as shown to the right of this paragraph. For information about See Using the standard task in SIL-2 safety applications 1-1 Where to find updated information on GuardLogix controller and 1-4 DeviceNet Safety I/O certified series and firmware revisions iii

4 iv Summary of Changes

5 Table of Contents Preface Introduction P-1 Manual Set-Up P-1 Understanding Terminology P-2 Related Documentation P-3 Chapter 1 SIL Concept SIL 3 Certification Functional Verification Tests GuardLogix Architecture for SIL 3 Applications GuardLogix System Components Safety Certifications and Compliances Agency Certifications GuardLogix PFD and PFH Specifications Definitions of PFD and PFH PFD and PFH Calculations SIL Compliance Distribution and Weight Safety Reaction Times System Reaction Time Safety Task Reaction Time Safety Task Period and Safety Task Watchdog Contact Information When Device Failure Occurs Chapter 2 GuardLogix Controller System GuardLogix Controller Hardware Primary Controller Safety Partner Safety I/O Chassis Power Supplies CIP Safety Protocol Communication Bridges Programming Overview RSLogix 5000 Programming Software DeviceNet Safety I/O for the GuardLogix Control System Chapter 3 Overview Typical Safety Functions of DeviceNet Safety I/O Modules. 3-1 Safe State Diagnostics Status Data Status LEDs ON- or OFF-Delay Function Input and Output Line Conditioning I/O Module Connection Status v

6 Table of Contents vi How to Latch and Reset Faulted I/O Reaction Time Safety Considerations for I/O Modules on the Safety Network Ownership Configuration Signature I/O Module Replacement Understanding CIP Safety and the Safety Network Number Characteristics of Safety Tags, the Safety Task, and Safety Programs Chapter 4 The Routable CIP Safety Control System Unique Node Reference Safety Network Number Considerations for Assigning the SNN SNN for Safety Consumed Tags SNNs for Out-Of-Box Modules SNN for Safety Module with a Different Configuration Owner SNNs when Copying a Safety Project Chapter 5 Differentiating Between Standard and Safety Using Safety Tags Using Standard Tags in Safety Routines (Tag Mapping). 5-2 Understanding the Safety Task Safety Task Limitations Safety Task Execution Safety Programs Safety Routines Chapter 6 Safety Application Development Safety Concept Assumptions Basics of Application Development and Testing Commissioning Life Cycle Specification of the Control Function Create the Project Testing the Application Program Generating the Safety Signature Project Verification Test Confirm the Project Safety Validation Locking the GuardLogix Controller Downloading the Safety Application Program Uploading the Safety Application Program Online Editing Forcing

7 Table of Contents vii Inhibiting a Module Changing Your Application Program Performing Offline Edits Performing Online Edits Editing Your Project Monitoring Status and Handling Faults Chapter 7 Monitoring System Status CONNECTION_STATUS Data Get System Value (GSV) and Set System Value (SSV) Instructions GuardLogix System Faults Non-Recoverable Controller Faults Non-Recoverable Safety Faults Recoverable Faults Appendix A Safety Instructions Safety Application Instructions A-1 Standard Instruction Subset A-2 Appendix B Reaction Times System Reaction Time B-1 Logix System Reaction Time B-1 Simple Input-Logic-Output Chain B-2 Logic Chain Using Produced/Consumed Safety Tags... B-3 Factors Affecting Logix System Reaction Time Components B-4 Checklists for GuardLogix Safety Applications Appendix C Checklist for GuardLogix Controller System C-2 Checklist for DeviceNet Safety Inputs C-3 Checklist for DeviceNet Safety Outputs C-4 Checklist for Developing a Safety Application Program.... C-5 Glossary Index

8 Table of Contents viii

9 Preface Introduction This manual is intended to describe the GuardLogix Controller system, which is type-approved and certified for use in safety applications up to and including SIL 3 according to IEC 61508, and applications up to and including category (CAT) 4, according to EN You must read and understand the safety concepts and requirements presented in this manual prior to operating a GuardLogix controller-based safety system. Manual Set-Up This manual explains how the GuardLogix Control System can be used in safety applications up to and including SIL 3 according to IEC 61508, and applications up to and including category (CAT) 4, according to EN The following table describes the information available in each section. Section: Title: Description: Chapter 1 SIL Concept Introduction to the SIL concept and how it relates to the GuardLogix Control system. Chapter 2 GuardLogix Controller System Brief overview of the main components of the SIL 3-capable GuardLogix Control System. Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 7 DeviceNet Safety I/O for the GuardLogix Control System Understanding CIP Safety and the Safety Network Number Characteristics of Safety Tags, the Safety Task, and Safety Programs Safety Application Development Monitoring Status and Handling Faults Discussion of safety I/O for use in the GuardLogix Control System. Defines the Safety Network Number and provides guidelines for its use. Defines safety tags and provides guidelines for their use. Describes the Safety Task, safety programs and safety routines. Outlines the safety concept of the system, discusses the safety requirements affecting application program development, editing, upload/download, validation, and security. It also covers forcing data, and inhibiting the controller and I/O. Information on monitoring system status, and explanations of fault types. Appendix A Safety Instructions Mnemonics for Safety Application Instruction Set and acceptable standard Logix Instructions. Appendix B Reaction Times Calculations and explanations of system and controller Reaction Times. Appendix C Glossary Checklists for GuardLogix Safety Applications Checklists for GuardLogix system, I/O, and application program development. Definition of the terms used in this manual. 1

10 Preface 2 Understanding Terminology The following table defines acronyms used in this manual. Acronym: Full Term: Definition: 1oo2 One Out of Two Refers to the behavioral design of a multi-processor system. CIP Common Industrial Protocol A messaging protocol used by Logix5000 systems. DC Diagnostic Coverage The ratio of the detected failure rate to the total failure rate. EN European Norm. The official European Standard GSV Get System Value A ladder logic instruction that retrieves specified controller status information and places it in a destination tag. PC Personal Computer Computer used to interface with, and control, a Logix-based system via RSLogix 5000 programming software. PFD PFH SNN Probability of Failure on Demand Probability of Failure per Hour Safety Network Number The average probability of a system to fail to perform its design function on demand. The probability of a system to have a dangerous failure occur per hour. A unique number that identifies a safety network, or safety sub-net, across all networks in the safety system. SSV Set System Value A ladder logic instruction that sets controller system data. TUNID Target Unique Network Identifier A unique number identifying each safety I/O device that can act as a target.

11 Preface 3 Related Documentation The table below provides a listing of publications that contain important information about GuardLogix Controller systems. For Read this document Document number Information on installing the GuardLogix Controller GuardLogix Controller Installation Instructions 1756-IN045 Information on configuration and programming for the GuardLogix System Information on the GuardLogix Safety Application Instruction Set GuardLogix User Manual GuardLogix Safety Application Instruction Set Reference Manual 1756-UM RM095 Information on installing DeviceNet Safety I/O Modules DeviceNet Safety I/O Installation Instructions 1791DS-IN001 Information on using DeviceNet Safety I/O Modules DeviceNet Safety I/O User Manual 1791DS-UM001 Information on the Logix5000 Instruction Set Logix5000 General Instruction Set Reference Manual 1756-RM003 Information on programming Logix5000 controllers Logix Common Procedures Programming Manual 1756-PM001 Information on using RSLogix 5000 Import/Export Utility Logix Import Export Reference Manual 1756-RM084 If you would like a manual, you can: download a free electronic version from the internet at purchase a printed manual by contacting your local Allen-Bradley distributor or Rockwell Automation sales office.

12 Preface 4

13 Chapter 1 SIL Concept This chapter introduces you to the Safety Integrity Level (SIL) concept and how the GuardLogix Controller meets the requirements for SIL 3 certification. For information about: See page: SIL 3 Certification 1-1 Functional Verification Tests 1-2 GuardLogix Architecture for SIL 3 Applications 1-3 GuardLogix System Components 1-4 Safety Certifications and Compliances 1-5 Agency Certifications 1-6 Definitions of PFD and PFH 1-6 SIL Compliance Distribution and Weight 1-8 Safety Reaction Times 1-9 Safety Task Period and Safety Task Watchdog 1-10 Contact Information When Device Failure Occurs 1-10 SIL 3 Certification The GuardLogix Controller system is type-approved and certified for use in safety applications up to and including SIL 3 according to IEC 61508, and applications up to and including category (CAT) 4, according to EN SIL requirements are based on the standards current at the time of certification. In addition, the standard tasks within GuardLogix controllers can be used either for standard applications or SIL-2 safety applications as described in the Using ControlLogix in SIL-2 Applications Reference Manual, publication 1756-RM001. In either case, do not use SIL-2 or standard tasks and variables to build up safety loops of a higher level. The Safety Task is the only task certified for SIL-3 applications. IMPORTANT When the GuardLogix controller is in the maintenance or programming mode or the application has not been validated by the user, the user is responsible for maintaining safe conditions. 1

14 1-2 SIL Concept RSLogix 5000 programming software is required to create programs for the GuardLogix controller. The TÜV Rheinland has approved the GuardLogix Controller system for use in safety-related applications up to SIL 3, in which the de-energized state is considered to be the safe state. All of the examples related to I/O included in this manual are based on achieving de-energization as the safe state for typical Machine Safety and Emergency Shutdown (ESD) Systems. IMPORTANT The system user is responsible for: the set-up, SIL rating, and validation of any sensors or actuators connected to the GuardLogix system. project management and functional testing. access control to the safety system, including password handling. programming the application software and the device configurations in accordance with the information in this safety reference manual and the GuardLogix Controllers User Manual, publication number 1756-UM020. When applying Functional Safety, restrict access to qualified, authorized personnel who are trained and experienced. The Safety-Lock function, with passwords, is provided in RSLogix For information on using the Safety-Lock feature, refer to the GuardLogix Controllers User Manual, publication number 1756-UM020. Functional Verification Tests IEC requires the user to perform various functional verification tests of the equipment used in the system. Functional verification tests are performed at user-defined times. For example, functional verification test intervals can be once a year, once every fifteen years or whatever timeframe is appropriate. The GuardLogix controller has a functional verification test interval of 15 years. Other components of the system, such as Safety I/O modules, sensors, and actuators generally have shorter functional verification test intervals. The controller should be included in the functional verification testing of the other components in the safety system. IMPORTANT Users specific applications determine the timeframe for the functional verification test interval. However this is mainly related to Safety I/O modules and field instrumentation.

15 SIL Concept 1-3 GuardLogix Architecture for SIL 3 Applications The following illustration shows a typical SIL function, including: the overall safety function the GuardLogix portion of the overall safety function how other devices (for example, HMI) are connected, while operating outside the function Programming Software. Figure 1.1 Typical SIL Function HMI read-only access to safety tags Plant-wide Ethernet Overall Safety Function Switch SIL 3 GuardLogix System DeviceNet Safety I/O 1756-L6xS 1756-LSP 1756-ENBT 1756-DNB Actuator Sensor DeviceNet Safety CIP Safety DeviceNet Safety I/O Actuator Sensor DeviceNet Safety I/O SIL 3 GuardLogix System 1756-L6xS 1756-LSP 1756-ENBT 1756-DNB Actuator Sensor DeviceNet Safety To non-safety related systems outside GuardLogix SIL 3-certified function.

16 1-4 SIL Concept GuardLogix System Components Table 1.1 lists the SIL 3-certified GuardLogix components. Table 1.2 lists non-sil 3-certified components that may be used with SIL 3 GuardLogix systems. For the most current list of GuardLogix and DeviceNet Safety I/O certified series and firmware revisions, see Firmware revisions are available by visiting Table 1.1 SIL 3-Certified GuardLogix Components Device Type Catalog Number Description Primary Controller 1756-L61S Controller with 2 MB memory (ControlLogix556xS) 1756-L62S Controller with 4 MB memory Safety Partner 1756-LSP Safety Partner (ControlLogix55SP) DeviceNet Safety I/O Modules 1791DS-IB DS-IB8XOB8 1791DS-IB4XOW4 DeviceNet Safety Input Module DeviceNet Safety Input/Solid-State Output Module DeviceNet Safety Input/Relay Output Module Related Documentation (1) Installation Instructions 1756-IN DS-IN001 User Manual 1756-UM DS-UM001 (1) These publications are available from Rockwell Automation by visiting Table 1.2 Components Suitable for Use With SIL 3 Systems Device Type Catalog Number Description Chassis 1756-A4, A7, A10, A13, A17 Power Supply Communication Modules Programming Software (1) or higher. Series (1) Version (1) Instructions Installation Related Documentation (2) User Manual Chassis B NA 1756-IN080 None available for these catalog numbers 1756-PA72 AC Power supply C NA 1756-PB72 DC Power supply C NA 1756-PA75 AC Power supply B NA 1756-IN PB75 DC Power supply B NA 1756-PA75R AC Redundant power supply A NA 1756-IN PB75R DC Redundant power supply A NA 1756-ENBT EtherNet Bridge Module A IN019 ENET-UM DNB DeviceNet Bridge Module A IN566 DNET-UM xxxx RSLogix 5000 NA 14 NA consult Online Help (2) These publications are available from Rockwell Automation by visiting TIP Slots of a SIL 3 system chassis not used by the SIL 3 system may be populated with other ControlLogix modules that are certified to the Low Voltage and EMC Directives. Refer to to find the certificate for the Programmable Control ControlLogix Product Family.

17 SIL Concept 1-5 Safety Certifications and Compliances Table 1.3 lists the Logix products referenced in this manual and the safety certifications/compliances for which these products are approved when they are so marked. Table 1.3 Product Certifications Catalog Number: UL 508 CSA C22.2 No. 142 CSA C22.2 No. 213 CSA C22.2 No FM 3600, FM 3611 IEC IEC SIL 3 EN954-1 Cat. 4 ANSI RIA DNB X X X X 1756-ENBT X X X X 1756-L61S X X X X X X X X X 1756-L62S 1756-LSP X X X X X X X X X 1791DS-IB12 X X X X X 1791DS-IB8XOB8 X X X X X 1791DS-IB4XOW4 X X X X X 1756-A4, A7, A10, A13 & A17 X X X X X 1756-PA72 X X X X X 1756-PA75 X X X X X 1756-PB72 X X X X X 1756-PB75 X X X X X 1756-PA75R X X X X X 1756-PB75R X X X X X (1) In an emergency stop function, NFPA79_2002 requires that, as a final measure, electrical power is disconnected via electromechanical components. If the GuardLogix system, including safety I/O modules, does not provide an electromechanical output, you must fulfill the NFPA requirement through the use of additional electromechanical components NFPA 79 (1)

18 1-6 SIL Concept Agency Certifications GuardLogix user documentation typically lists the agency certifications for which the products are approved. If a product has achieved agency certification, it is marked as such on the product labeling. Product certifications are listed in the product s specifications table, as shown in the example below. Certification UL UL Listed Industrial Control Equipment CSA CSA Certified Process Control Equipment for Class I, Division 2 Group A,B,C,D Hazardous Locations FM CE C-Tick FM Approved Equipment for use in Class I Division 2 Group A,B,C,D Hazardous Locations European Union 89/336/EEC EMC and Low Voltage Directives, compliant with:en ; Industrial Emissions Australian Radio Communications Act, compliant with: AS/NZS 2064; Industrial Emissions TÜV Functional Safety: SIL 1 to 3, according to IEC 61508; Category 1 to 4, according to EN GuardLogix PFD and PFH Specifications Definitions of PFD and PFH Safety-related systems can be classified as operating in either a low demand mode, or in a high demand/continuous mode. IEC quantifies this classification by stating that the frequency of demands for operation of the safety system is no greater than once per year in the low demand mode, or greater than once per year in high demand/continuous mode. The SIL value for a low demand safety-related system is directly related to order-of-magnitude ranges of its average probability of failure to satisfactorily perform its safety function on demand or, simply, probability of failure on demand (PFD). The SIL value for a high demand/continuous mode safety-related system is directly related to the probability of a dangerous failure occurring per hour (PFH). Although PFD and PFH values are usually associated with each of the three elements making up a safety-related system (the sensors, the actuators, and the logic element), they can be associated with each component of the logic element, that is, each module of a programmable controller.

19 SIL Concept 1-7 PFD and PFH Calculations The PFD and PFH calculations in the tables below are based on the equations from Part 6 of IEC with the following assumptions: The architecture is 1oo2. A detected error in either channel will result in the outputs being transitioned to their safe state. The functional verification test interval (T1) is 15 years (131,400 hours). The hardware fault tolerance equals 1. The safe failure fraction is 99.1%. The fraction of detected common cause failures (β D ) is 0.5%. The fraction of undetected common cause failures (β) is 1.0% Table 1.4 PFD Values for GuardLogix Controller System Components Component Functional Verification PFD Test Interval 1756-L6xS and 1756-LSP 15 years 8.5E DS-IB DS-IB8XOB8 1791DS-IB4XOW4 3 months 9.58E-7 6 months 1.92E-6 1 year 3.83E-6 2 years 7.66E-6 3 months 1.21E-6 6 months 2.41E-6 1 year 4.82E-6 2 years 9.64E-6 3 months 5.81E-6 6 months 1.18 E-5 Table 1.5 PFH Values for GuardLogix Controller System Components Component Functional Verification PFH Test Interval 1756-L6xS and 1756-LSP 15 years 1.9E DS-IB12 3 months 8.75E DS-IB8XOB8 3 months 1.11E DS-IB4XOW4 3 months 5.24E-9

20 Logix5562S Logix55LSP DeviceNet EtherNet 1-8 SIL Concept Figure 1.2 PFH Calculation Example 1791DS-IB12 sensor GuardLogix Controller LOOP DS-IB4XOX4 actuator sensor LOOP 2 actuator sensor 1791DS-IB8XOB8 To calculate the Logix System PFH for each safety loop in the simple example system shown above, sum the PFH values for each component in the loop. Table 1.6 below provides a simplified example of PFH value calculations for each safety loop in Figure 1.2, using the PFH values and test intervals from Table 1.5 on page 1-7. Table 1.6 PFH Calculations by Safety Loop Loop 1 Loop 2 Component PFH Component PFH 1791DS-IB E DS-IB8XOB8 1.11E-10 GuardLogix Controller 1.9 E-10 GuardLogix Controller 1.9 E DS-IB4XOX4 5.24E DS-IB4XOX4 5.24E-9 Loop 1 Total PFH = 6.305E-9 Loop 2 Total PFH = 5.541E-9 When calculating PFH values, you must take into account the specific requirements of your application, including test intervals. SIL Compliance Distribution and Weight The programmable controller may conservatively be assumed to contribute 10% of the reliability burden. A SIL 3 system may need to incorporate multiple inputs for critical sensors and input devices, as well as dual outputs connected in series to dual actuators dependent on SIL assessments for the safety related system.

21 SIL Concept 1-9 Figure 1.3 Reliability Burden 10% of the PFD +V 40% of the PFD Sensor Input Module Controller Output Module Actuator 50% of the PFD Sensor Input Module Safety Reaction Times System Reaction Time The system reaction time is the amount of time from a safety-related event as input to the system until the system is in the safe state. Faults within the system can also have an effect upon the reaction time of the system. The system reaction time is the sum of the following reaction times: Sensor Reaction Time Input Safety Task Output + Reaction + Reaction + Reaction + Time Time Time Actuator Reaction Time Each of the times listed above is variably dependent on factors such as the type of I/O module and instructions used in the program. For a list of the available safety instructions, see Appendix A in this publication. For a full description of safety instruction logic operation and execution, refer to the GuardLogix Safety Application Instruction Set Reference Manual, publication 1756-RM095. For a full description of standard instruction logic operation and execution, refer to the Logix5000 Controllers General Instruction Set Reference Manual, publication 1756-RM003.

22 1-10 SIL Concept Safety Task Reaction Time The Safety Task Reaction Time is the worst-case delay from any input change presented to the controller until the processed output is set by the output producer. It is less than or equal to the sum of the Safety Task Period and the Safety Task Watchdog. Safety Task Period and Safety Task Watchdog The Safety Task Period is the period at which the Safety Task executes. The Safety Task Watchdog time is the maximum permissible time for Safety Task processing. If the cycle time exceeds the Safety Task Watchdog time, a non-recoverable safety fault occurs in the controller and outputs transition to the safe state (off) automatically. For more information on faults, see Chapter 7, Monitoring Status and Handling Faults. The Safety Task Watchdog time is user-defined, but must be less than or equal to the Safety Task Period. The Safety Task Watchdog time is set in the task properties window of RSLogix 5000 software. This value can be modified online, regardless of controller mode, but it cannot be changed once the controller is Safety-Locked or once a Safety Signature is created. See Chapter 6 for more information on Safety-Lock and the Safety Signature. For information on calculating the safety system reaction times, see Appendix B, Reaction Times. Contact Information When Device Failure Occurs If you experience a failure with any SIL 3-certified device, contact your local Rockwell Automation distributor. With this contact, you can: return the device to Rockwell Automation so the failure is appropriately logged for the catalog number affected and a record is made of the failure. request a failure analysis (if necessary) to try to determine the cause of the failure.

23 Chapter 2 GuardLogix Controller System This chapter discusses the GuardLogix Control System components, including the primary controller and safety partner, chassis, power supply, communication bridges, and the programming software. For a brief listing of components suitable for use in SIL 3 applications, see Table 1.2 on page 1-4. For more detailed and up-to-date information see When installing a GuardLogix controller, follow the information in the GuardLogix Controllers Installation Instructions, publication 1756-IN045. GuardLogix Controller Hardware The GuardLogix controller consists of a Primary Controller, catalog number 1756-L61S or 1756-L62S, and a Safety Partner, catalog number 1756-LSP. These two modules work in a 1oo2 architecture to create the SIL 3-capable controller. They are described in the following sections. Both the Primary Controller and Safety Partner perform power-up and run-time functional diagnostic tests of all safety-related components in the controller. Both also feature status LEDs. For details on LED operation, refer to the GuardLogix Controllers User Manual, publication 1756-UM020. IMPORTANT LEDs are not reliable indicators for safety functions. They should be used only for general diagnostics during commissioning or troubleshooting. Do not attempt to use LEDs as operational indicators. Primary Controller The Primary Controller is the processor that performs standard and safety functions and communicates with the Safety Partner for safety-related functions in the GuardLogix Control System. The Primary Controller consists of a central processor, I/O interface and memory. 1

24 2-2 GuardLogix Controller System Safety Partner In order to satisfy SIL 3 requirements, a Safety Partner, catalog number 1756-LSP, must be installed in the slot immediately to the right of the Primary Controller. The Safety Partner is a co-processor that provides redundancy for safety-related functions in the system. The Safety Partner is configured by the Primary Controller. Only a single download of the user program to the primary controller is required. The Safety Partner s operating mode is controlled by the Primary Controller. Safety I/O For information on DeviceNet Safety I/O modules for use with the GuardLogix controller, see Chapter 3. Chassis The 1756-Axx chassis provides the physical connections between modules and the GuardLogix system. Any failure, though unlikely, would be detected as a failure by one or more of the active components of the system. Therefore, the chassis is not relevant to the safety discussion. Power Supplies ControlLogix power supplies suitable for use in SIL 3 applications include: 1756-PA72 AC power supply 1756-PA75 AC power supply 1756-PB72 DC power supply 1756-PB75 DC power supply 1756-PA75R AC power supply (redundant) 1756-PB75R DC power supply (redundant) 1756-PSCA or 1756-PSCA2 Redundant power supply chassis adapter (required for use with redundant power supplies) No extra configuration or wiring is required for SIL 3 operation of the ControlLogix power supplies. Any failure, though unlikely, would be detected as a failure by one or more of the active components of the GuardLogix system. Therefore, the power supply is not relevant to the safety discussion.

25 GuardLogix Controller System 2-3 CIP Safety Protocol Safety-related communication between GuardLogix controllers takes place via produced and consumed safety tags. These safety tags use the CIP Safety protocol, which is designed to preserve data integrity during communication. For more information on safety tags, see Chapter 5, Characteristics of Safety Tags, the Safety Task, and Safety Programs. Communication Bridges The following communication interface modules are available to facilitate communication over Ethernet/IP and DeviceNet networks via the CIP Safety protocol: 1756-ENBT EtherNet/IP Communication Interface Module 1756-DNB DeviceNet Interface Module IMPORTANT Due to the design of the CIP Safety control system, CIP safety bridge devices, like the 1756-ENBT and 1756-DNB, are not required to be SIL 3-certified. EtherNet/IP Peer-to-peer safety communication between GuardLogix controllers is possible via EtherNet/IP through the use of 1756-ENBT bridge modules. Figure 2.1 Peer-to-Peer Communication via 1756-ENBT and EtherNet/IP EtherNet/IP Controller A 1756-L62S 1756-LSP 1756-ENBT 1756-L62S 1756-LSP 1756-ENBT Controller B TIP Peer-to-peer safety communication between two GuardLogix controllers in the same chassis is also possible via the backplane. Backplane 1756-L62S 1756-LSP 1756-L62S 1756-LSP

26 2-4 GuardLogix Controller System DeviceNet Safety The 1756-DNB DeviceNet Interface module lets the GuardLogix controller control and exchange data with DeviceNet Safety I/O modules. Figure 2.2 DeviceNet Communications via 1756-DNB 1756-L62S 1756-LSP 1756-DNB DeviceNet Safety I/O Module DeviceNet Safety I/O Module Programming Overview RSLogix 5000 Programming Software The programming software for the GuardLogix Controller is RSLogix 5000, version 14.x or higher. RSLogix 5000 is not safety-certified. RSLogix 5000 is used to define the location, ownership, and configuration of I/O modules and controllers. The software is also used for creation, testing, and debugging application logic. Initially, only relay ladder logic is supported in the GuardLogix Safety Task. See Appendix A for information on the set of logic instructions available for safety applications. Authorized personnel may change an application program, but only by using one of the processes described in Changing Your Application Program on page 6-9.

27 Chapter 3 DeviceNet Safety I/O for the GuardLogix Control System Overview Before operating a GuardLogix safety system containing DeviceNet Safety I/O, you must read, understand, and follow the installation, operation, and safety information provided in the publications listed in Table 1.1 on page 1-4. Field DeviceNet Safety I/O can be connected to safety input and output devices, allowing these devices to be controlled by the GuardLogix control system. For safety data, I/O communications are performed through safety connections using the DeviceNet Safety Protocol; logic is processed in the safety controller. Typical Safety Functions of DeviceNet Safety I/O Modules Safe State The following is treated as the safe state by safety I/O modules. Safety outputs: OFF Output data to network: OFF DeviceNet Output to Network: OFF Safety Status Output OFF Input The DeviceNet Safety I/O modules should be used for applications that are in the safe state when the safety output turns OFF and the output data to the network turns OFF. Diagnostics DeviceNet Safety I/O modules perform self-diagnostics when the power is turned ON and periodically during operation. If a diagnostic failure is detected, the safety outputs and output data to the network are turned OFF. 1

28 3-2 DeviceNet Safety I/O for the GuardLogix Control System Status Data In addition to input and output data, some DeviceNet Safety I/O modules support status data to monitor the I/O circuits. Refer to your module s product documentation. Status LEDs The DeviceNet Safety I/O modules include status LEDs. For details on LED operation, refer to the product documentation for your specific module. IMPORTANT LEDs are not reliable indicators for safety functions. They should be used only for general diagnostics during commissioning or troubleshooting. Do not attempt to use LEDs as operational indicators. ON- or OFF-Delay Function Some DeviceNet Safety I/O modules may support ON-delay and OFF-delay functions for input signals. You must include OFF-delay times when calculating system reaction time. See Appendix B for information on system reaction time. Input and Output Line Conditioning DeviceNet Safety I/O modules provide pulse test and monitoring capabilities. If the module detects a failure, it sets the offending input or output to its Safe state and reports the failure to the controller. The failure indication is made via the input or output point status, and is maintained for a configurable amount of time, or until the failure is repaired, which ever comes first. IMPORTANT Ladder logic must be included in the application program to latch these I/O point failures and ensure proper restart behavior.

29 DeviceNet Safety I/O for the GuardLogix Control System 3-3 I/O Module Connection Status A CIP Safety system provides connnection status for each I/O device in the safety system. If an input connection failure is detected, the operating system sets all associated inputs to their de-energized (Safe) state, and reports the failure to the ladder logic. If an output connection failure is detected, the operating system can only report the failure to the ladder logic; the outputs are de-energized by the output module. IMPORTANT Ladder logic must be included in the application program to monitor and latch any connection failures and ensure proper restart behavior. How to Latch and Reset Faulted I/O The diagrams in Figure 3.1 and Figure 3.2 provide examples of the ladder logic required to latch and reset an I/O module connection or point failure. Figure 3.1 shows the ladder logic required for an input point, Figure 3.2 shows the ladder logic required for an output point. IMPORTANT Both of these diagrams are examples, and are for illustrative purposes only. The suitability of this logic depends upon your specific system requirements.

30 3-4 DeviceNet Safety I/O for the GuardLogix Control System Figure 3.1 Example Ladder Logic to Latch and Reset an Input Input Module Connection Faulted Input Faulted *** Internal Tag *** L Input Point Status Fault Reset Fault Reset Oneshot ONS Input Module Connection Faulted Input Point Status Input Faulted *** Internal Tag *** U Input Point Data Input Faulted *** Internal Tag *** Output *** Internal Tag *** The first rung latches an internal indication that either the module connection or the specific input point has failed. The second rung resets the internal indication, but only if the fault has been repaired, and only on the rising edge of the Fault Reset signal. This prevents the safety function from automatically restarting if the Fault Reset signal gets stuck on. The third rung shows the input point data used in combination with the internal fault indication to control an output. The output is internal data that may be used in combinational logic later to drive an actual output. If an actual output is used directly, it may or may not require logic similar to that shown in Figure 3.2 for latching and resetting output connection failures. The Fault Reset contact shown in these examples is typically activated as a result of operator action. The Fault Reset could be derived as a result of combinational logic or directly from an input point (in which case it may or may not require conditioning of its own).

31 DeviceNet Safety I/O for the GuardLogix Control System 3-5 Figure 3.2 Example Ladder Logic to Latch and Reset an Output Output Module Connection Faulted Output Faulted *** Internal Tag *** L Output Point Status Fault Reset Fault Reset Oneshot ONS Output Module Connection Faulted Output Point Status Output Faulted *** Internal Tag *** U User defined logic to activate output Output Faulted *** Internal Tag *** Output Point Data The ladder logic in Figure 3.2 has the same latch and reset concept as that shown in Figure 3.1. The first rung latches an internal indication that either the module connection or the specific output point has failed. The second rung resets the internal indication, but only if the fault has been repaired, and only on the rising edge of the Fault Reset signal. This prevents the safety function from automatically restarting if the reset signal gets stuck on. The third rung includes application-specific logic to drive the state of an output point. This logic is conditioned by the output faulted internal indicator. Reaction Time The input reaction time is the time from when an input signal is changed to when network data is sent. The output reaction time is the time from when a network signal is received to when the state of output terminal is changed. For information on determining the input and output reaction times, refer to the product documentation for your specific DeviceNet Safety I/O module. See Appendix B for information on calculating the system reaction time.

32 3-6 DeviceNet Safety I/O for the GuardLogix Control System Safety Considerations for I/O Modules on the Safety Network You must commission all devices with the MAC ID and baud rate, if necessary, before their installation on the safety network. Ownership Every module in the GuardLogix system is owned by only one controller in the architecture. When a controller owns an I/O module, it stores the module s configuration data, as defined by the user. This data controls how the module behaves in the system. TIP Ownership applies to outputs. An output or output assembly can only have one owner. A module can only be configured by one originator, which automatically becomes the configuration owner for that module. No other device can send configuration data to the module. TIP You can return the module to the Out-of-Box condition by selecting the Reset Ownership button from the Safety tab of the Module Properties dialog in RSLogix Configuration Signature The Configuration Signature defines the module s configuration and lets a non-owner device establish a connection. It can be read and monitored. The Configuration signature is used to uniquely identify a module s configuration in several operations: During download from a configuration tool, the Configuration Signature provides you with a means to check that the device and the configuration tool agree on the information downloaded. During device replacement, the Configuration Signature allows you to verify that the configuration in the configuration tool is the correct configuration. If the originator is used to automatically configure a device, the Configuration Signature indicates whether reconfiguration is necessary and ensures the integrity of the operation. During connection establishment, the originator and the target devices use the Configuration Signature to ensure that both devices are using the same configuration data.

33 DeviceNet Safety I/O for the GuardLogix Control System 3-7 The Configuration Signature is auto-generated by RSLogix 5000 when an I/O module is added to the GuardLogix controller project. I/O Module Replacement The replacement of safety devices requires that the replacement device be configured properly and that the replacement device s operation be user-verified. ATTENTION! During replacement or functional testing of a module, the safety of the system must not rely on any portion of the affected module. Two options are available for I/O module replacement. You can configure the controller to always automatically configure the replacement module, or you can choose to allow automatic configuration via the controller only when a Safety Signature does not exist. These options are located on the Safety tab of the Controller Properties dialog. Which option you choose depends upon whether any portion of the CIP Safety System is being relied upon to maintain SIL 3 behavior

34 3-8 DeviceNet Safety I/O for the GuardLogix Control System during the replacement and functional testing of the module, as described below. ATTENTION! Enable the Configure Always feature only if the entire routable CIP Safety Control System is not being relied on to maintain SIL 3 behavior during the replacement and functional testing of a module. If other parts of the CIP Safety Control System are being relied upon to maintain SIL 3, ensure that the controller s Configure Always feature is disabled. Do not place any modules in the Out-of-Box condition on any CIP Safety Network when the Configure Always feature is enabled, except while following the module replacement procedure in the GuardLogix Controllers User Manual, publication number 1756-UM020. Refer to the GuardLogix Controller User Manual, publication number 1756-UM020, for more information on replacing an I/O module.

35 Chapter 4 Understanding CIP Safety and the Safety Network Number To understand the safety requirements of a CIP Safety Control System, including the Safety Network Number (SNN), you must first understand how communications are routable in CIP Control Systems. The Routable CIP Safety Control System The CIP Safety control system represents a set of interconnected CIP Safety Devices. The routable system represents the extent of potential mis-routing of packets from an originator to a target within the CIP Safety control system. The system is isolated such that there are no other connections into the system. For example, because the system below cannot be interconnected to another CIP Safety system through a larger (i.e. plant-wide) Ethernet backbone, it illustrates the extent of a routable CIP Safety system. Figure 4.1 CIP Safety System Example Router/ Firewall Switch Switch 1756-L62S 1756-LSP 1756-DNB 1756-ENB 1756-L62S 1756-LSP 1756-DNB 1756-ENB 1756-L62S 1756-LSP 1756-DNB 1756-ENB GuardPLC Safety I/O Safety I/O Safety I/O Safety I/O Safety I/O Safety I/O Safety I/O Safety I/O 1

36 4-2 Understanding CIP Safety and the Safety Network Number Unique Node Reference The CIP Safety protocol is an end-node to end-node safety protocol. The CIP Safety protocol allows the routing of CIP Safety messages to and from CIP Safety devices through non-certified bridges, switches, and routers. To prevent errors in non-certified bridges, switches, or routers from becoming dangerous, each end node within a routable CIP Safety Control System must have a unique node reference. The unique node reference is a combination of a Safety Network Number (SNN) and the Node Address of the node. Safety Network Number The Safety Network Number (SNN) is assigned by a software configuration tool or by the user. Each DeviceNet network that contains safety nodes must have at least one unique SNN. Each ControlBus chassis that contains one or more safety devices must have at least one unique SNN. Safety Network Numbers assigned to each safety network or network sub-net must be unique. TIP Multiple SNNs can be assigned to a DeviceNet subnet or a ControlBus chassis that contains more than one safety device. However, for simplicity, we recommend that each DeviceNet subnet have one and only one unique SNN. This is also the case for each ControlBus chassis. Figure 4.2 CIP Safety Example with SNNs Router/ Firewall Switch Switch 1756-L62S Safety I/O Safety I/O 1756-LSP 1756-DNB 1756-ENB 1756-L62S 1756-LSP 1756-DNB 1756-ENB SNN_1 SNN_3 SNN_5 Safety I/O 1756-L62S Safety I/O Safety Safety SNN_2 I/O SNN_4 I/O SNN_ LSP 1756-DNB 1756-ENB GuardPLC Safety I/O Safety I/O

37 Understanding CIP Safety and the Safety Network Number 4-3 Each CIP Safety device must be configured with an SNN. Any device that originates a safety connection to another safety device must be configured with the SNN of the target device. If the CIP Safety System is in the start-up process prior to the functional safety testing of the system, the originating device may be used to set the unique node reference into the device. The SNN used by the system is a six-byte hexadecimal number. The SNN can be set and viewed in one of two formats: time-based or manual. When the Time-based format is selected, the SNN represents a localized date and time. When the manual format is selected, the SNN represents a network type and a decimal value from 1 to Figure 4.3 SNN Formats The assignment of a time-based SNN is automatic when creating a new GuardLogix Safety Controller project and adding new Safety I/O modules. Manual manipulation of SNN s is required in the following situations: If safety consumed tags are used. If the project will consume safety input data from a module whose configuration is owned by some other device. If a safety project is copied to a different hardware installation within the same routable CIP Safety system. IMPORTANT If you assign SNNs manually, take care to ensure that system expansion does not result in duplication of SNN and Node Address combinations.

38 4-4 Understanding CIP Safety and the Safety Network Number Considerations for Assigning the SNN SNN for Safety Consumed Tags When a safety controller that contains produced safety tags is added to the I/O Configuration tree, the SNN of the producing controller must be entered. The SNN may be copied from the producing controller s project and pasted into the new controller being added to the I/O Configuration tree. Refer to the GuardLogix Controllers User Manual, publication number 1756-UM020, for information on how to copy and paste an SNN. SNNs for Out-Of-Box Modules The new SNN of an out-of-box DeviceNet Safety I/O module is set in that module the first time that it is connected to the safety system and prior to the Safety Signature being applied to the GuardLogix controller project. IMPORTANT To allow the SNN to be set in the I/O modules, connect to the DeviceNet Safety I/O module prior to applying the Safety Signature to the safety controller project. The SNN assignment will then be tested as part of the normal safety verification that occurs after the Signature is applied and before the safety system is authorized. SNN for Safety Module with a Different Configuration Owner When a safety I/O module whose configuration is owned by some other device is added to the I/O Configuration tree, an SNN will automatically be assigned by RSLogix If the module s configuration owner had already assigned an SNN to the module or network, the original SNN will need to be re-entered on the module s Safety Network Number dialog. Refer to the GuardLogix Controllers User Manual, publication number 1756-UM020, for information on changing, copying, and pasting Safety Network Numbers.

39 Understanding CIP Safety and the Safety Network Number 4-5 SNNs when Copying a Safety Project ATTENTION If a safety project is copied to another project intended for a different hardware installation and that installation may reside within the same routable CIP Safety System, the SNN must be changed, as described in the GuardLogix Controllers User Manual, publication number 1756-UM020, to ensure that SNN is not repeated.

40 4-6 Understanding CIP Safety and the Safety Network Number

41 Chapter 5 Characteristics of Safety Tags, the Safety Task, and Safety Programs Differentiating Between Standard and Safety Both standard (non-safety-related) and safety-related components can be used in the GuardLogix Control System. However, you must make a logical and visible distinction between the standard and safety-related portions of the application. RSLogix 5000 provides this differentiation via safety tags, the Safety Task, safety programs, and safety routines. Using Safety Tags The GuardLogix Control System supports the use of both standard and safety tags in the same project. However, the programming software differentiates standard from safety tags, both visually and operationally. Safety tags have all the attributes of standard tags with the addition of mechanisms to provide SIL 3 data integrity. You can declare safety tags of any valid data type. Tags that cannot be used as safety tags are those with the following data types: AXIS_CONSUMED AXIS_GENERIC AXIS_SERVO AXIS_SERVO_DRIVE AXIS_VIRTUAL MOTION_GROUP MESSAGE COORDINATE_SYSTEM REAL IMPORTANT Aliasing between standard and safety tags is prohibited in safety applications. Tags classified as safety tags must be either controller-scoped or safety-program-scoped. Safety-program-scoped safety tags can only be read by or written to via a safety routine scoped in the same safety program. Controller-scoped safety tags can be read, but not written to, by standard routines. As you develop your application logic, you must 1

42 5-2 Characteristics of Safety Tags, the Safety Task, and Safety Programs differentiate safety controller-scoped tags from standard controller-scoped tags. Tags associated with safety I/O and produced or consumed safety data must be controller-scoped safety tags. IMPORTANT Any controller-scoped safety tag is readable by any standard routine, but the update rate and time is based on the execution of the Safety Task. This means that safety tags are updated at the Safety Task periodic rate, not the network RPI. Safety tag input data arrives at the controller based on the Safety Task RPI time. The range of the Safety Task RPI for safety inputs and safety consumed tags is 1 to 500 ms. Using Standard Tags in Safety Routines (Tag Mapping) Controller-scoped standard tags can be mapped into safety tags, providing you with a mechanism to synchronize standard and safety actions. For information on how to map tags, see the GuardLogix Controllers User Manual, publication number 1756-UM020. ATTENTION! When using standard data in a safety routine, you are responsible for providing a reliable means of ensuring that the data is used in a safe manner. One way to do this is to qualify the standard data with safety data, as shown in the following example. Figure 5.1 Qualifying Standard Data with Safety Data MappedBooleanTag Node30ComboModule:I.Pt07Data Node30ComboModule:O.Pt03Data LatchOneShot ONS Node30ComboModule:O.Pt03Data Safety input qualifier for mapped tag Latch circuit to prevent automatic restart if the standard input (MappedTag) is failed in a stuck at 1 state. Safety output

43 Characteristics of Safety Tags, the Safety Task, and Safety Programs 5-3 Understanding the Safety Task Creation of a GuardLogix project automatically creates a single Safety Task. The Safety Task has these additional characteristics: The GuardLogix controller is the only controller that supports the Safety Task. The Safety Task cannot be deleted or inhibited. The GuardLogix controller supports a single Safety Task. Within the Safety Task, you can schedule multiple safety programs composed of multiple safety routines. You cannot schedule or execute standard routines from within the Safety Task. The Safety Task is a periodic/timed task with a user-selectable task priority and watchdog. It should be the controller s top priority and the user-defined program watchdog must be set to accommodate fluctuations in the execution of the Safety Task. Safety Task Limitations You specify both the Safety Task Period and the Safety Task Watchdog. The Safety Task Period is the period at which the Safety Task executes. The Safety Task Watchdog is the maximum time allowed from the start of Safety Task scheduled execution to its completion. For more information on the Safety Task Watchdog, see Appendix B, Reaction Times. The Safety Task Period is limited to a maximum of 500 ms and cannot be modified online. Ensure that the Safety Task has enough time to finish before it is triggered again. Safety Task Watchdog Timeout, a non-recoverable safety fault in the GuardLogix controller, occurs if the Safety Task is triggered while it is still executing from the previous trigger. See Chapter 7, Monitoring Status and Handling Faults, for more information.

44 5-4 Characteristics of Safety Tags, the Safety Task, and Safety Programs Safety Task Execution The Safety Task executes in the same manner as standard periodic tasks, with the following exceptions: The Safety Task does not begin executing until the Primary Controller and Safety Partner have established their control partnership and the Coordinated System Time (CST) is synchronized. However, standard tasks begin executing as soon as the controller transitions to RUN mode. Safety input tags and safety-consumed tags are updated at the beginning of Safety Task execution. Safety input values are frozen at the start of Safety Task execution. As a result, timer-related instructions (e.g. TON, TOF, etc.) will not include time elapsed during a single Safety Task execution. They will keep accurate time from one task execution to another, but the time base will not change during the Safety Task execution. ATTENTION This behavior differs from standard task execution.! For standard tags that are mapped to safety tags, the standard tag values are copied into Safety Task memory at the start of Safety Task and do not change during execution. Safety-produced tags are produced at the conclusion of Safety Task execution. Safety output tags are sent to safety outputs at the conclusion of Safety Task execution. The Safety Task responds to mode changes (i.e. Run to Program or Program to Run) at timed intervals. As a result, the Safety Task may take more than one task period, but always less than two, to make a mode transition.

45 Characteristics of Safety Tags, the Safety Task, and Safety Programs 5-5 IMPORTANT While Safety-Unlocked and without a Safety Signature, the controller prevents simultaneous write access to safety memory from the Safety Task and communications commands. As a result, the Safety Task can be held off until a communications update completes. The time required for the update varies by tag size. Therefore, safety connection and/or safety watchdog timeouts could occur. (For example, if you make online edits when the Safety Task rate is set to 1 ms, a safety watchdog timeout could occur.) To compensate for the hold-off time due to a communications update, add 2 ms to the Safety Watchdog time. NOTE: When the controller is Safety-Locked or a Safety Signature exists, this situation cannot occur. Safety Programs A safety program has all the attributes of a standard program, except that it can only be scheduled in the Safety Task. A safety program may also define program-scoped safety tags. A safety program may be scheduled or unscheduled. A safety program can contain only safety components. All of the routines in a safety program must be safety routines. A safety program cannot contain standard routines or standard tags. Safety Routines A safety routine has all the attributes of a standard routine, except that it can only exist in a safety program. One safety routine may be designated as the main routine. Another safety routine may be designated as the fault routine. Only safety instructions may be used in safety routines. For a listing of safety application instructions, see Appendix A. ATTENTION To preserve SIL 3, you must ensure that your safety logic does not attempt to read or write standard tags.!

46 5-6 Characteristics of Safety Tags, the Safety Task, and Safety Programs

47 Chapter 6 Safety Application Development Safety Concept Assumptions The safety concept assumes that: 1. those responsible for creating, operating, and maintaining the application are fully qualified, specially trained personnel, experienced in safety systems. 2. the user applies the logic correctly, meaning that programming errors can be detected. Programming errors can be detected by strict adherence to specifications, programming and naming rules. 3. the user performs a critical analysis of their application and uses all possible measures to detect a failure. 4. the user confirms all application downloads via a manual check of the Safety Signature. 5. before the initial startup of a safety-related system, the entire system is checked by a complete functional test. Basics of Application Development and Testing The application program for the intended SIL 3 system should be developed by the system integrator and/or user trained and experienced in safety applications. The developer must follow good design practices, including the use of: Functional specifications, including: Flow charts Timing diagrams Sequence charts Program review Program validation 1

48 6-2 Safety Application Development Commissioning Life Cycle The flowchart below shows the steps required for commissioning a GuardLogix system. The items in bold text are explained in the following sections. Figure 6.1 Commissioning the System Specify the Control Function Create Project Online Create Project Offline Attach to Controller and Download Test the Application Program Generate Safety Signature Make required modifications Project Verification Test Tests Passed? Yes Confirm the Project No Delete Safety Signature Record Safety Signature Fill out the Safety Checklists in Appendix C Safety Validation (Independent Review) Project Valid? No Yes Lock the Controller / End

49 Safety Application Development 6-3 Specification of the Control Function You must create a specification for your control function. Use this specification to verify that program logic correctly and fully addresses your application s functional and safety control requirements. The specification may be presented in a variety of formats, depending on your application. However, the specification must be a detailed description that includes (if applicable): Sequence of operations Flow and timing diagrams Sequence charts Program description Program print out Verbal descriptions of the steps with step conditions and actuators to be controlled, including: input definitions output definitions I/O wiring diagrams and references theory of operation Matrix or table of stepped conditions and the actuators to be controlled, including the sequence and timing diagrams Definition of marginal conditions, for example, operating modes, EMERGENCY STOP etc. The I/O-portion of the specification must contain the analysis of field circuits, that is, the type of sensors and actuators: Sensors (Digital or Analog) Signal in standard operation (dormant current principle for digital sensors, sensors OFF means no signal) Determination of redundancies required for SIL levels Discrepancy monitoring and visualization, including the user s diagnostic logic Actuators Position and activation in standard operation (normally OFF) Safe reaction/positioning when switching OFF or power failure. Discrepancy monitoring and visualization, including the user s diagnostic logic

50 6-4 Safety Application Development Create the Project The logic and instructions used in programming the application must be: easy to understand easy to trace easy to change easy to test All logic should be reviewed and tested. Keep safety-related logic and non-safety-related logic separate. Label the Program The application program is clearly identified by one of the following: Name Date Revision Any other user identification Testing the Application Program This step consists of any combination of Run and Program mode, online or offline edits, upload and download, and informal testing that is required to get an application running properly. Generating the Safety Signature To help ensure that a specific project is downloaded to the correct (target) controller, the GuardLogix controller and RSLogix 5000 support the creation of a Safety Signature. The Safety Signature uniquely identifies each project, including its logic, data, tags, etc. The safety signature is composed of an ID (identification number), date, and time.

51 Safety Application Development 6-5 You can generate the Safety Signature if all of the following conditions are true: the controller is online, the controller is in program mode, the controller is Safety-Unlocked, the controller has no safety forces or pending online safety edits, and the Safety Task status is OK. Once application program testing is complete, you must generate the Safety Signature. The programming software automatically uploads the Safety Signature after it is generated. IMPORTANT To verify the integrity of every download, you must manually record the Safety Signature after initial creation and check the Safety Signature after every download to ensure that it matches the original. You can delete the Safety Signature only when the GuardLogix controller is Safety-Unlocked and the controller is not in the Run mode (keyswitch in RUN position). When a Safety Signature exists, the following actions are not permitted within the Safety Task: Online/offline programming or editing Forcing Safety I/O Data manipulation (except through routine logic) Project Verification Test To check the application program for adherence to the specification, you must generate a suitable set of test cases covering the application. The set of test cases must be filed and retained as the test specification. You must include a set of tests to prove the validity of the calculations (formulas) used in your application logic. Equivalent range tests are acceptable. These are tests within the defined value ranges, at the limits, or in invalid value ranges. The necessary number of test cases depends on the formulas used and must comprise critical value pairs.

52 6-6 Safety Application Development Active simulation with sources (field devices) must also be included, since it is the only way to verify that the sensors and actuators in the system are wired correctly. Verify the operation of programmed functions by manually manipulating sensors and actuators. You must also include tests to verify the reaction to wiring faults and network communication faults. Project Verification includes required functional verification tests of fault routines, input and output channels, etc. to ensure that the safety system operates properly. See Functional Verification Tests on page 1-2 for more information. Confirm the Project You must print or view the project, and manually compare the uploaded safety I/O and controller configurations, safety data, and safety task program logic to ensure that the correct safety components were downloaded, tested, and retained in the safety application program. The steps below illustrate one method for confirming the project: 1. With the controller in Program mode, save the project. Answer Yes to the Upload Tag Values prompt. 2. With RSLogix 5000 offline, save the project with a new name, such as Offlineprojectname.ACD, where projectname is the name of your project. 3. Close the project. 4. Rename the original project archive file to Originalprojectname.ACD, where projectname is the name of your project. 5. With the controller still in Program mode, upload the project from the controller. Name the uploaded project Onlineprojectname.ACD, where projectname is the name of your project. Answer Yes to the Upload Tag Values prompt. 6. Invoke another instance of RSLogix 5000 and open the project named Originalprojectname.ACD.

53 Safety Application Development Use the two instances of RSLogix 5000 to compare the following: all of the properties of the GuardLogix controller and DeviceNet Safety I/O modules all of the properties of the Safety Task, safety programs and safety routines all of the logic in the safety routines. TIP RSLogix 5000 features a Program Compare utility that may be helpful in identifying changed safety components, but it must not be used in place of a manual compare. Safety Validation An independent, third-party review of the safety system may be required before the system is approved for operation. Locking the GuardLogix Controller The GuardLogix Controller system can be Safety-Locked to protect safety control components from modification. The Safety-Lock feature applies only to safety components, such as the Safety Task, safety routines, safety I/O, Safety Signature, etc. However, Safety-Locking alone does not satisfy SIL 3 requirements. No portion of a safety component can be modified while the controller is in the Safety-Locked state. When the controller is Safety-Locked, the following actions are not permitted in the Safety Task: Online/offline programming or editing Forcing safety I/O Data manipulation (except through routine logic) Generating or deleting the Safety Signature The default state of the controller is Safety-Unlocked. You may place the controller in a Safety-Locked state regardless of whether the controller is online or offline, and regardless of whether you have the original source of the program. However, no safety forces or pending online safety edits may be present. Safety-Locked or -Unlocked status cannot be modified when the keyswitch is in the RUN position.

54 6-8 Safety Application Development To provide an additional layer of protection, separate passwords may be used for Safety-Locking or -Unlocking the controller. Passwords are optional. Downloading the Safety Application Program Upon download, full application testing is required unless a Safety Signature exists. IMPORTANT To verify the integrity of every download, you must manually record the Safety Signature after initial creation and check the Safety Signature after every download to ensure that it matches the original. Downloads to a Safety-Locked GuardLogix controller are allowed only if the Safety Signature, the hardware series, and the OS version of the offline project all match those contained in the target GuardLogix controller and the controller s Safety Task status is OK. IMPORTANT If the Safety Signature does not match and the controller is Safety-Locked, you must unlock the controller to download. Downloading to the controller deletes the Safety Signature. As a result, you must re-validate the application. Uploading the Safety Application Program If the GuardLogix controller contains a Safety Signature, the Safety Signature will be uploaded with the project. This means that any changes to offline data will be overwritten as a result of the upload. Online Editing If there is no Safety Signature and the controller is Safety-Unlocked, you can perform online edits to your safety routines. Pending edits cannot exist when the controller is Safety-Locked or when there is a Safety Signature. Online edits may exist when the controller is Safety-Locked. However, they may not be assembled, cancelled, etc. TIP Online edits in standard routines are unaffected by the Safety-Locked or -Unlocked state. See page 6-9 for more information on making edits to your application program.

55 Safety Application Development 6-9 Forcing All data contained in an I/O, produced, or consumed safety tag, including CONNECTION_STATUS, can be forced while the project is Safety-Unlocked and no Safety Signature exists. However, forces must be uninstalled, not just disabled, on all safety tags before the safety project can be Safety-Locked or a Safety Signature can be generated. You cannot force safety tags while the project is Safety-Locked or when a Safety Signature exists. TIP You can install and uninstall forces on standard tags regardless of the Safety-Locked or -Unlocked state. Inhibiting a Module Inhibiting a module is configured at the safety I/O module level. All modules on the branch past the inhibited module are also inhibited. If either a safety I/O module or a producer controller is inhibited, the consumed safety data for each connection is reset to 0. You cannot inhibit or uninhibit Safety I/O modules or producer controllers if the application is Safety-Locked or a Safety Signature exists. Changing Your Application Program The following rules apply to changing your application program in RSLogix 5000: Only authorized, specially-trained personnel can make program edits. These personnel should use all supervisory methods available, for example, using the controller keyswitch and software password protections. When authorized, specially-trained personnel make program edits, they assume the central safety responsibility while the changes are in progress. These personnel must also maintain safe application operation. When editing online, you must use an alternate protection mechanism to maintain the safety of the system. You must sufficiently document all program edits, including: authorization impact analysis execution test information revision information If online edits exist in the standard routines only, those edits are not required to be validated before returning to normal operation.

56 6-10 Safety Application Development You must ensure that changes to the standard routine, with respect to timing and tag mapping, are acceptable to your safety application. You can edit the logic portion of your program while Offline or Online, as described in the following sections. Performing Offline Edits When offline edits are made to standard program elements only, and the Safety Signature matches following a download, you can resume operation. When offline edits affect the safety program, you must revalidate the entire application before resuming operation. The flowchart on page 6-11 illustrates the process for offline editing. Performing Online Edits If online edits affect the safety program, you must revalidate the entire application before resuming operation. The flowchart on page 6-11 illustrates the process for online editing. TIP Limit online edits to minor program modifications such as setpoint changes or logic additions, deletions and modifications. Online edits are affected by the Safety-Lock and Safety Signature features of the GuardLogix controller. See Generating the Safety Signature on page 6-4 and Locking the GuardLogix Controller on page 6-7 for more information. For detailed information on how to edit ladder logic in RSLogix 5000 while online, see the Logix5000 Controllers Quick Start, publication 1756-QS001.

57 Safety Application Development 6-11 Editing Your Project Figure 6.2 Online and Offline Edit Process Offline Edit Online Edit Open Project Attach to Controller No Any Safety Changes? Yes Unlock the Controller Any Safety Changes? Yes No Make Desired Modifications to Standard Logic Make Desired Modifications to Standard Logic Attach to Controller and Download Delete Safety Signature Make Desired Modifications to Safety Logic Unlock the Controller Delete Safety Signature Make Desired Modifications Test the Application Program Test the Application Program Attach to Controller and Download Test the Application Program END Confirm the Project Generate Safety Signature Project Verification Test Make Required Modifications Tests Passed? Yes Confirm the Project No Delete Safety Signature END Record Safety Signature Safety Validation (Independent Review) Project Valid? No Yes Lock the Controller END

58 6-12 Safety Application Development

59 Chapter 7 Monitoring Status and Handling Faults The GuardLogix architecture provides the user many ways of detecting and reacting to faults in the system. The first way that users can handle faults is to make sure they have completed the checklists for their application (see Appendix C). This chapter discusses methods of monitoring system status, and describes system faults and fault routines. Monitoring System Status To monitor system status, you can view the status of safety tag connections. You can also determine current operating status by interrogating various device objects. It is your responsibility to determine what data is most appropriate to initiate a shutdown sequence. CONNECTION_STATUS Data The first member of the tag structure associated with safety input data and produced/consumed safety tag data contains the status of the connection. This member is a pre-defined data type called CONNECTION_STATUS.. 1