1756-RM001B-EN-P, Using ControlLogix in SIL2 ... - Tuv-fs.com

Using ControlLogixin SIL2 Applications1756-SeriesSafety Reference Manual

Summary of ChangesIntroductionThis release of this document contains updated information. Changesare designated by change bars in margin, as shown to the left.New and RevisedInformationWhile change bars are located throughout the manual wherever texthas changed (for example, to correct typographical errors from theprevious revision), Table Summary of Changes.1 lists the mostsignificant new and revised information included in this release of theControlLogix digital I/O modules user manual.Table Summary of Changes.1 New and Revised InformationInformation About Location New or RevisedUpdated terminology page Preface-2 RevisedUpdated information for:Revisedand• ControlLogix ProductProbability of Failure onDemand Calculationspage 1-10• ControlLogix ProductProbability of UndetectedDangerous Failure perHourpage 1-12Proof test intervals page 1-5 RevisedCalibrating ControlLogix input and page 6-13 and page 6-20 Revisedoutput modulesSecurity in a SIL2-certified page 8-4New and revisedControlLogix applicationOnline editing page 9-6 RevisedSpurious failure estimates Appendix D NewAdditional sample PFDcalculationsAppendix ENew1 Publication 1756-RM001B-EN-P - October 2003

Summary of Changes 2Notes:Publication 1756-RM001B-EN-P - October 2003

PrefaceIntroductionThis application manual is intended to describe the ControlLogixControl System components available from Rockwell Automation thatare suitable for use in SIL2 applications.Manual Set-UpThis manual is designed to make clear how the ControlLogix ControlSystem can be SIL2-certified. Table Preface.1 lists the informationavailable in each section.Table Preface.1Section: Title: Description:Chapter 1 SIL Policy Introduction to the SIL policy and how thatpolicy relates to the ControlLogix system.Chapter 2 The ControlLogix System Brief overview of all the components present inthe SIL2-certified ControlLogix system.Chapter 3 ControlLogix SystemHardwareDescription of the ControlLogix power suppliesand chassis used in the SIL2-certifiedControlLogix system.Chapter 4 ControlLogix Controller Description of the ControlLogix controller usedin the SIL2-certified ControlLogix system.Chapter 5ControlLogix CommunicationsModulesDescription of the ControlLogix communicationsmodules used in the SIL2-certified ControlLogixsystem.Chapter 6 ControlLogix I/O Modules Description of the ControlLogix I/O modulesused in the SIL2-certified ControlLogix system.Chapter 7Chapter 8Chapter 9Chapter 10Appendix AAppendix BFaults in the ControlLogixSystemGeneral Requirements forApplication SoftwareTechnical SIL2 Requirementsfor the Application ProgramUse and Application ofHuman to Machine InterfacesResponse Times inControlLogixSystem Self-Testing andUser-Programmed ResponsesDescription of two common conditions thatcause a fault in a ControlLogix system.Guidelines for application development inRSLogix 5000 as they relate to SIL2.Description of technical safety necessary inSIL2-certified ControlLogix applications.Description of the precautions and techniquesthat should be used with HMI devices as theyare used in SIL2-certified ControlLogixapplications.Additional information on the componentspresent in a SIL2-certified ControlLogixapplication.Explanation of the self-testing and systemresponses to test results that are available inthe ControlLogix system.1 Publication 1756-RM001B-EN-P - October 2003

Preface 2Table Preface.1Section: Title: Description:Appendix CAdditional Information onHandling Faults in theControlLogix SystemAdditional information that may help the userhandle faults.Appendix D Spurious Failure Estimates Spurious failure rates based on field returns.Appendix E Sample Probability of Failure Additional PFD calculations based on proof teston Demand (PFD) Calculations intervals of 2 years and 4 years.Understanding TerminologyThe following table defines acronyms used in this manual.Table Preface.2 List of Acronyms Used Throughout the Safety Application ManualAcronym: Full Term: Definition:CIPControl andInformationProtocolA messaging protocol used by Logix5000systems. It is a native communications protocolused on ControlNet communications networks,among others.DCDiagnosticCoverageThe ratio of the detected failure rate to the totalfailure rate.EN European Norm. The official European StandardGSV Get System Value A ladder logic output instruction that retrievesspecified controller status information and placesit in a destination tag.MTBFMean Time Average time between failure occurrences.Between FailuresMTTRMean Time toRestorationAverage time needed to restore normal operationafter a failure has occurred.PADTPCPFDPFHProgramming andDebugging ToolPersonalComputerProbability ofFailure onDemandProbability ofFailure per HourRSLogix 5000 software used to program anddebug a SIL2-certified ControlLogix application.Computer used to interface with, and control, aControlLogix system via RSLogix 5000programming software.The average probability of a system to fail toperform its design function on demand.The probability of a system to have a dangerousfailure occur per hour.Publication 1756-RM001B-EN-P - October 2003

Table of ContentsChapter 1SIL Policy Introduction to SIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1SIL2 Certification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4Proof Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5SIL2-Certified ControlLogix System Components. . . . . . . . . 1-6Safety Certifications and Compliances . . . . . . . . . . . . . . . . 1-7Hardware Designs and Firmware Functions . . . . . . . . . . . . 1-8Difference Between PFD and PFH . . . . . . . . . . . . . . . . . . . 1-8SIL Compliance Distribution and Weight . . . . . . . . . . . . . . 1-14Agency Certifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15Response Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15Program Watchdog Time in ControlLogix System . . . . . . . . 1-16Contact Information When Device Failure Occurs. . . . . . . . 1-16Chapter 2The ControlLogix System General Overview of ControlLogix Platform . . . . . . . . . . . . 2-1Overview of the ControlLogix Architecture. . . . . . . . . . . . . 2-2Module Fault Reporting . . . . . . . . . . . . . . . . . . . . . . . . 2-3Fault Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3Data Echo Communication Check. . . . . . . . . . . . . . . . . 2-4Pulse Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6Other Unique Features that Aid Diagnostics . . . . . . . . . 2-7Checklist for the ControlLogix System . . . . . . . . . . . . . . . . 2-7Chapter 3ControlLogix System Hardware Introduction to the Hardware . . . . . . . . . . . . . . . . . . . . . . 3-1ControlLogix Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2ControlLogix Power Supplies. . . . . . . . . . . . . . . . . . . . . . . 3-2Non-Redundant Power Supply . . . . . . . . . . . . . . . . . . . 3-3Redundant Power Supply. . . . . . . . . . . . . . . . . . . . . . . 3-3Recommendations for System Hardware Use . . . . . . . . . . . 3-4Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4Related ControlLogix Hardware Documentation . . . . . . . . . 3-5Chapter 4ControlLogix Controller Introduction to the Controller . . . . . . . . . . . . . . . . . . . . . . 4-1Recommendations for Controller Use . . . . . . . . . . . . . . . . . 4-2Related Controller Documentation . . . . . . . . . . . . . . . . . . . 4-21 Publication 1756-RM001B-EN-P - October 2003

Table of Contents 2ControlLogix CommunicationsModulesChapteR 5Introduction to Communication Modules . . . . . . . . . . . . . . 5-1ControlNet Bridge Module. . . . . . . . . . . . . . . . . . . . . . . . . 5-2ControlNet Cabling . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2ControlNet Module Diagnostic Coverage. . . . . . . . . . . . 5-2Ethernet Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2Ethernet Versus ControlNet . . . . . . . . . . . . . . . . . . . . . . . . 5-2Recommendations for Communications Modules Use . . . . . 5-3Related Communications Modules Documentation . . . . . . . 5-4Chapter 6ControlLogix I/O Modules Overview of ControlLogix I/O Modules . . . . . . . . . . . . . . . 6-1Module Fault Reporting for any ControlLogix I/O Module. . 6-4Using Digital Input Modules . . . . . . . . . . . . . . . . . . . . . . . 6-4General Considerations when using Any ControlLogixDigital Input Module . . . . . . . . . . . . . . . . . . . . . . . . . . 6-5Wiring ControlLogix Digital Input Modules. . . . . . . . . . . . . 6-6Using Digital Output Modules . . . . . . . . . . . . . . . . . . . . . . 6-7General Considerations when using Any ControlLogixDigital Output Module . . . . . . . . . . . . . . . . . . . . . . . . . 6-8Wiring ControlLogix Digital Output Modules . . . . . . . . . . . 6-10Diagnostic Digital Output Modules . . . . . . . . . . . . . . . . 6-10Standard Digital Output Modules . . . . . . . . . . . . . . . . . 6-11Using Analog Input Modules . . . . . . . . . . . . . . . . . . . . . . . 6-13General Considerations when using Any ControlLogixAnalog Input Module . . . . . . . . . . . . . . . . . . . . . . . . . . 6-13Wiring ControlLogix Analog Input Modules . . . . . . . . . . . . 6-16Wiring the Single-Ended Input Module in Voltage Mode 6-16Wiring the Single-Ended Input Module in Current Mode 6-17Wiring the Thermocouple Input Module . . . . . . . . . . . . 6-18Wiring the RTD Input Module . . . . . . . . . . . . . . . . . . . 6-19Using Analog Output Modules. . . . . . . . . . . . . . . . . . . . . . 6-20General Considerations when using Any ControlLogixAnalog Output Module. . . . . . . . . . . . . . . . . . . . . . . . . 6-20Wiring ControlLogix Analog Output Modules . . . . . . . . . . . 6-23Wiring the Analog Output Module in Voltage Mode . . . 6-23Wiring the Analog Output Module in Current Mode . . . 6-24Checklist for SIL Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-25Checklist for SIL Outputs. . . . . . . . . . . . . . . . . . . . . . . . . . 6-26Publication 1756-RM001B-EN-P - October 2003

Table of Contents 3Chapter 7Faults in the ControlLogix System Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1Checking Keyswitch Position with GSV Instruction. . . . . . . 7-1Examining an Analog Input Module’s High Alarm. . . . . . . . 7-3General Requirements forApplication SoftwareTechnical SIL2 Requirements forthe Application ProgramUse and Application of Human toMachine InterfacesChapter 8Software for SIL2-Related Systems . . . . . . . . . . . . . . . . . . . 8-1SIL2 Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-2Safety Concept of the ControlLogix system . . . . . . . . . . 8-2General Guidelines for Application Software Development . 8-2Check the Created Application Program . . . . . . . . . . . . 8-3Possibilities of Program Identification . . . . . . . . . . . . . . 8-3Forcing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-4ControlLogix System Operational Modes . . . . . . . . . . . . . . 8-5Checklist for the Creation of an Application Program . . . . . 8-6Chapter 9General Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1Basics of Programming. . . . . . . . . . . . . . . . . . . . . . . . . 9-2SIL Task/Program Instructions . . . . . . . . . . . . . . . . . . . . . . 9-4Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 9-4Commissioning Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 9-5Changing Your Application Program . . . . . . . . . . . . . . . . . 9-6Forcing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-8Chapter 10Using Precautions and Techniques with HMI . . . . . . . . . . . 10-1Accessing Safety-Related Systems . . . . . . . . . . . . . . . . . 10-1Changing Parameters in Safety-Related Systems. . . . . . . 10-2Changing Parameters in Non-Safety-Related Systems . . . 10-3Appendix AResponse Times in ControlLogix Digital Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1Local Chassis Configuration . . . . . . . . . . . . . . . . . . . . . A-1Remote Chassis Configuration . . . . . . . . . . . . . . . . . . . A-2Analog Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3Local Chassis Configuration . . . . . . . . . . . . . . . . . . . . . A-3Remote Chassis Configuration . . . . . . . . . . . . . . . . . . . A-4System Self-Testing andUser-Programmed ResponsesAppendix BValidation Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1System Self Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-1Publication 1756-RM001B-EN-P - October 2003

Table of Contents 4Additional Information onHandling Faults in theControlLogix SystemSpurious Failure EstimatesSample Probability of Failure onDemand (PFD) CalculationsAppendix CIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1Appendix DAppendix EProof Test Interval = 2 Years . . . . . . . . . . . . . . . . . . . . . . . E-1Proof Test Interval = 4 Years . . . . . . . . . . . . . . . . . . . . . . . E-3IndexPublication 1756-RM001B-EN-P - October 2003

Chapter 1SIL PolicyThis chapter introduces you to the SIL policy and how theControlLogix system meets the requirements for SIL2 certification.For information about:See page:Introduction to SIL 1-1SIL2 Certification 1-4Proof Tests 1-5SIL2-Certified ControlLogix System Components 1-6Safety Certifications and Compliances 1-7Hardware Designs and Firmware Functions 1-8Difference Between PFD and PFH 1-8SIL Compliance Distribution and Weight 1-14Agency Certifications 1-15Response Times 1-15Program Watchdog Time in ControlLogix System 1-16Contact Information When Device Failure Occurs 1-16Introduction to SILCertain catalog numbers (listed in Table 1.1 on page 1-6) of theControlLogix system are type-approved and certified for use in SIL2applications, according to IEC 61508 and AK4 applications accordingto DIN V19250. SIL requirements are based on the standards current atthe time of certification.These requirements consist of mean time between failures (MTBF),probability of failure, failure rates, diagnostic coverage and safe failurefractions that fulfill SIL2 criteria. The results make the ControlLogixsystem suitable up to, and including, SIL2. When the ControlLogixsystem is in the maintenance or programming mode, the user isresponsible for maintaining a safe state.For support in creation of programs, the PADT (Programming andDebugging Tool) is required. The PADT for ControlLogix isRSLogix 5000, per IEC 61131-3, and this Safety Reference Manual.1 Publication 1756-RM001B-EN-P - October 2003

1-2 SIL PolicyThe TUV Rheinland has approved the ControlLogix system for use inup to SIL 2 safety related applications in which the de-energized stateis considered to be the safe state. All of the examples related to I/Oincluded in this manual are based on achieving de-energization as thesafe state for typical Emergency Shutdown (ESD) Systems.The ControlLogix is a modular and configurable system with theability to pre-configure outputs and other responses to faultconditions. As such, a system can be designed to meet requirementsfor “hold last state" in the event of a fault so that the system can beused in up to SIL 2 level Fire and Gas and other Applications thatrequire that output signals to actuators remain on. By understandingthe behavior of the ControlLogix system for an emergency shutdownapplication, the system design can incorporate appropriate measuresto meet other application requirements. These measures relate to thecontrol of outputs and actuators which must remain on to be in a safestate. The other requirements for SIL2 regarding inputs from sensors,software etc. must also be met. The measures and modificationswhich relate to Gas and Fire are listed below.• The use of a manual over-ride is necessary to ensure theoperator can maintain the desired control in the event of aController Failure. This is similar in concept to the function ofthe external relay or redundant outputs required to ensure ade-energized state is achieved for an ESD system should afailure occur that would prevent this from normally occurringsuch as a shorted output driver. The system knows it has afailure but the failure mode requires an independent means tomaintain control and either remove power or provide analternate path to maintain power to the end actuator.• If the application cannot tolerate an output that can fail shorted(energized) then an external means such as a relay or otheroutput must be wired in series to remove power when the failshorted condition occurs. (Refer to Figure 6.8 on page 6-11)If the application cannot tolerate an output that fails open(deenergized) then an external means such as a manual overrideor output must be wired in parallel. (Refer to the manualoverride Figure 1.1 on page 1-3). The user must supply thealternative means and develop the application program toinitiate the alternate means of removing or continuing to supplypower in the event the main output fails.Publication 1756-RM001B-EN-P - October 2003

SIL Policy 1-3• This manual over-ride circuit is shown in Figure 1.1. It iscomposed of a hardwired set of contacts from a selector switchor push-button. One Normally Open contact provides for thebypass of power from the Controller output directly to theactuator. The other is a Normally closed contact to remove orisolate the controller output• An application program needs to be generated to monitor thediagnostic output modules for dangerous failures such asshorted or open output driver channels. Diagnostic outputmodules must be configured to hold last state in the event of afault.• A diagnostic alarm must be generated to inform the operatorthat manual control is required.• The faulted module must be replaced within a reasonable timeframe.• Any time a fault is detected the user must annunciate the fault toan operator by some means (for example, an alarm light).Figure 1.1L1Manual OverrideActuatorL2 or Ground43379FaultAlarm to OperatorPublication 1756-RM001B-EN-P - October 2003

1-4 SIL PolicySIL2 CertificationFigure 1.2 shows a typical SIL loop, including:• the overall safety loop• the ControlLogix portion of the overall safety loop• how other devices (for example, HMI) connect to the loop,while operating outside the loopFigure 1.2Programming SoftwareFor SIL applications, a programmingterminal is not normally connected.HMIFor Diagnostics and Visualization (read-only access to controllers inthe safety loop). For more information, see Chapter 10.Plant-wide Ethernet/SerialOverall Safety LoopSIL2-certified ControlLogix components’ portion of the overall safety loopSensorENBTCNBCNBCNBActuatorControlNetTo othersafety relatedControlLogixremote I/OchassisControlNetTo non-safety related systems outside theControlLogix portion of the SIL2-certified loop.For more information, see Chapter 5.Publication 1756-RM001B-EN-P - October 2003

SIL Policy 1-5IMPORTANTThe system user is responsible for:• the set-up, SIL rating and validation of anysensors or actuators connected to theControlLogix control system.• project management and functional testing.• programming the application software and themodule configuration according to thedescription in the following chapters.The SIL2 portion of the certified system excludes thedevelopment tools and display/human machineinterface (HMI) devices; these tools and devices arenot part of the run time control loop.Proof TestsIEC 61508 requires the user to perform various proof tests of theequipment used in the system. Proof tests are performed atuser-defined times (for example, proof test intervals can be once ayear, once every two years or whatever timeframe is appropriate) andinclude some of the following tests:• Testing of all fault routines to verify that process parameters aremonitored properly and the system reacts properly when a faultcondition arises.• Testing of digital input or output channels to verify that they arenot stuck in the ON or OFF state.• Calibration of analog input and output modules to verify thataccurate data is obtained from and used on the modules.IMPORTANTUsers’ specific applications will determine thetimeframe for the proof test interval.However, keep in mind that the Probability ofFailure on Demand (PFD) calculations listed inTable 1.3 on page 1-10 use a proof test interval ofonce per year. If the proof test interval is changed,the information must be recalculated.For sample PFD calculations for proof test intervalsof 2 and 4 years, see Appendix EFor more information on system proof tests, see Chapter 2, TheControlLogix System. For more information on the necessary I/Omodule proof tests, see Chapter 6, ControlLogix I/O Modules.Publication 1756-RM001B-EN-P - October 2003

1-6 SIL PolicySIL2-Certified ControlLogixSystem ComponentsTable 1.1 lists the components available for use in a SIL2-certifiedControlLogix system.Device Type:CatalogNumber:Hardware 1756-A4, A7, A10,A13 & A17Table 1.1 Components For Use in the SIL 2 SystemDescription:Series:FirmwareRevision:(2)Related Documentation (3) withMore Information on CatalogNumber:Installation User Manual:Instructions:ControlLogix Chassis B NA 1756-IN080 None availablefor these catalognumbers1756-PA75 AC Power supply A NA 1756-5.781756-PB75 DC Power supply A NA1756-PA75R AC Redundant power supply A NA 1756-IN5731756-PB75R DC Redundant power supply A NA1756-PSCA Redundant Power SupplyChassis Adapter ModuleA NA 1756-IN574Controller 1756-L55M16 ControlLogix 7.5Mb Controller A 10.27 1756-IN101 1756-UM001I/O Modules 1756-IA16I AC Isolated Input Module A 2.2 1756-IN059 1756-UM0581756-IA8D AC Diagnostic Input Module A 2.6 1756-IN0551756-IB16D DC Diagnostic Input Module A 2.6 1756-IN0691756-IB16I DC Isolated Input Module A 2.2 1756-IN0101756-OA16I AC Isolated Output Module A 2.1 1756-IN0091756-OA8D AC Diagnostic Input Module A 2.4 1756-IN0571756-OB16D DC Diagnostic Output Module A 2.3 1756-IN0581756-OB16I DC Isolated Output Module A 2.1 1756-IN5121756-OB8EI DC Isolated Output Module A 2.3 1756-IN0121756-OX8I Isolated Relay Output Module A 2.1 1756-IN5131756-IF8 Analog Input Module A 1.5 1756-IN040 1756-6.5.91756-IR6I RTD Input module A 1.9 1756-IN0141756-IT6I Thermocouple Input module A 1.9 1756-IN0371756-OF8 Analog Output Module A 1.5 1756-5.41CommunicationModules1756-CNB1756-CNBR1756-ENBT (1)ControlNet CommunicationModuleRedundant ControlNetCommunication ModuleEtherNet CommunicationModuleD 5.27 1756-IN571 1756-6.5.3D 5.27A 1.33 1756-IN019 1756-UM050(1) The 1756-ENBT module is included in this table because this module can be used to connect the safety system to the EtherNet/IP network However, the EtherNet/IPnetwork is not SIL2-certified and cannot be used as part of the SIL2-certified system. It can only be used to connect non-safety devices to the safety system. Because themodule is not part of the safety system, it is not listed in PDF and PFH calculations in Table 1.3 and Table 1.4 later in this chapter.(2)Users must use these series and firmware revisions for their application to be SIL2 certified. Firmware revisions are available by visitinghttp://support.rockwellautomation.com/ControlFlash/(3) These publications are available from Rockwell Automation by visiting http://www.theautomationbookstore.com or http://www.ab.com/manuals.Publication 1756-RM001B-EN-P - October 2003

SIL Policy 1-7Safety Certifications andCompliancesTable 1.2 lists the ControlLogix products referenced in this manualand the safety certifications/compliances for which these products areapproved when they are so marked.Table 1.2 Product CertificationsCatalogNumber:UL 508 UL 1604 CSAC22.2CSAC22.2CSAC22.2FM 3600,FM 3611IEC 61131-2No. 142No. 213No. 10101756-Axx X X X X X1756-CNB X X X X1756-CNBR X X X X1756-ENBT X X X X1756-IA16I X X X X X1756-IA8D X X X X X1756-IB16D X X X X X1756-IB16I X X X X X1756-IF8 X X X X1756-IR6I X X X X X1756-IT6I X X X X X1756-L55, X X X XL55Mxx1756-OA16I X X X X X1756-OA8D X X X X X1756-OB16D X X X X X1756-OB16I X X X X X1756-OB8EI X X X X X1756-OF8 X X X X X1756-OX8I X X X X X1756-PA75R X X X X X1756-PB75R X X X X X1756-PSCA X X X X XPublication 1756-RM001B-EN-P - October 2003

1-8 SIL PolicyHardware Designs andFirmware FunctionsDiagnostic hardware designs and firmware functions designed into theControlLogix platform allow it to achieve at least SIL2 certification in asingle-controller configuration. These diagnostic features areincorporated into specific ControlLogix components, such as the:• processor• power supply• I/O modules• backplaneand are covered in subsequent sections. The ControlLogix platform’sdesigns, features and characteristics make it one of the most intelligentplatforms.Some of the ControlLogix features include:• multiple microprocessors which check themselves and eachother• I/O modules with internal microprocessors• an I/O architecture that includes modules with backplaneconnections to the main central processing unit (CPU).The backplane connections, along with configuration identities,permit a new level of I/O module diagnostics unavailable in earlierplatforms.Difference Between PFDand PFHSafety-related systems can be classified as operating in either a lowdemand mode, or in a high demand/continuous mode. IEC 61508quantifies this classification by stating that the frequency of demandsfor operation of the safety system is no greater than once per year inthe low demand mode, or greater than once per year in highdemand/continuous mode. Generally speaking however, the once peryear is expanded to ten times per year.The SIL value for a low demand safety-related system is relateddirectly to order-of-magnitude ranges of its average probability offailure to satisfactorily perform its safety function on demand or,simply, probability of failure on demand (PFD). The SIL value for ahigh demand/continuous mode safety-related system is relateddirectly to the probability of dangerous failure occurring per hour(PFH).Although PFD and PFH values are usually associated with each of thethree elements making up a safety-related system (the sensors, theactuators, the logic element), they can be associated with eachcomponent of the logic element, that is, each module of aProgrammable Controller.Publication 1756-RM001B-EN-P - October 2003

SIL Policy 1-9Table 1.3 and Table 1.4 present values of the PFDs and PFHs for thespecific ControlLogix products evaluated by TUV.The Mean Time Between Failure (MTBF) values listed in Table 1.3 andTable 1.4 are calculated from field data for each product. A minimuminstalled base must exist for at least one year before a value iscalculated. It is assumed that the products are in use 16 hours/day, 5days/week, 52 weeks/year. It can be noted that these values areupdated monthly and that the values tabulated below were currentwhen this publication was prepared. The Failure Rate (λ) column ofTable 1.3 and Table 1.4 is just the reciprocal of MTBF.For the example PFD calculations, several assumptions were made:• 50% of the failures of each product reported to RockwellAutomation are dangerous failures.• The diagnostic coverage (DC) is 90% for modules used in a 1oo1architecture.• The diagnostic coverage is 60% for modules used in a 1oo2architecture.• The fraction of detected common cause failures (β D ) is 1%.• The fraction of undetected common cause failures (β) is 2%Because Rockwell Automation does not and can not know everypotential application for each product, these very conservativeassumptions had to be made to do the calculations.For the sample calculations presented in this manual, the followingvalues were used as the two application-dependent variables:• The Mean Time to Restoration (MTTR) is ten hours.• The Proof Test Interval (T 1 ) is one year (8760 hours). (1)The equation for PFD, from IEC61508, for a 1oo1 architecture is:PFD = (λ DU + λ DD )t CE = λ D t CE = λ/2 [T 1 /2 (1 - DC) + MTTR]– where: λ DU is the undetected dangerous failure rate (perhour)λ DD is the detected dangerous failure rate (per hour)t CE is the "channel equivalent mean down time"λ D is the dangerous failure rate (per hour)λ is the overall product failure rate (per hour)(1) For PFD calculations using proof test intervals of 2 and 4 years, see Appendix E.Publication 1756-RM001B-EN-P - October 2003

1-10 SIL PolicyCatalogNumberDescriptionFor a 1oo2 architecture, the PFD equation is much more complex. SeeIEC61508 Part 6 Annex B.The PFD values in Table 1.3 are given for the architecture that mustbe used for specific products to achieve SIL 2.Table 1.4 includes the same MTBF and Failure Rate values asTable 1.3 but adds calculated PFH values for high demand/continuousmode operation.The equation for PFH, from IEC61508, for a 1oo1 architecture is:PFH = λ DU = λ/2 (1 - DC)1756-Axx ControlLogix Chassis 40,143,919 (2)For a 1oo2 architecture, see Part 6 of IEC61508. The values inTable 1.4 are given for the architecture that must be used for specificproducts to achieve SIL2.Table 1.3ControlLogix Product Probability of Failure on Demand CalculationsMean Time λ (5) Calculated PFD:Between Failure(MTBF) (1) 1oo1 architecture 1oo2 architecture(average (3) )2.49E-085.58E-061756-CNB ControlNet Bridge 3,596,087 (2) 2.78E-07 6.23E-051756-CNBR Redundant ControlNet Bridge 3,385,813 (2) 2.95E-07 6.62E-051756-IA16I AC Isolated Input 4,144,192 2.41E-07 4.30E-061756-IA8D AC Diagnostic Input 3,856,320 2.59E-07 4.63E-061756-IB16D DC Diagnostic Input 7,386,774 1.35E-07 2.40E-061756-IB16I DC Isolated Input 3,562,624 2.81E-07 5.02E-061756-IF8 Analog Input 1,690,694 5.91E-07 1.08E-051756-IR6I RTD Input 3,456,960 2.89E-07 5.17E-061756-IT6I Thermocouple Input 4,784,000 2.09E-07 3.72E-06Publication 1756-RM001B-EN-P - October 2003

SIL Policy 1-11Catalog DescriptionMean Time λ (5) Calculated PFD:NumberBetween Failure(MTBF) (1) 1oo1 architecture 1oo2 architecture1756-L55M16 ControlLogix 5555 Controller 2,855,348 (2) 3.50E-07 7.84E-051756-OA16I AC Isolated Output 1,994,720 5.01E-07 9.07E-061756-OA8D AC Diagnostic Output 3,839,680 2.60E-07 5.83E-051756-OB16D DC Diagnostic Output 4,520,534 2.21E-07 4.96E-051756-OB16I DC Isolated Output 1,703,520 5.87E-07 1.07E-051756-OB8EI DC Fused Output 1,239,680 8.07E-07 1.48E-051756-OF8 Analog Output 2,054,694 4.87E-07 8.80E-061756-OX8I Contact Output 6,639,360 1.51E-07 2.67E-061756-PA75 AC Power Supply 7,301,935 (2) 1.37E-07 3.07E-051756-PA75R AC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 5.11E-081756-PB75 DC Power Supply 7,100,760 (2) 1.41E-07 3.15E-051756-PB75R DC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 5.11E-081756-PSCAPower Sup Chassis AdapterModule45,146,727 (2) 2.21E-08 4.96E-06(1) MTBF measured in hours.(2) Calculated using field based values for components(3) Average = The arithmetic average of the MTBFs of all five Chassis (1756-A4, A7, A10, A13, and A17)(4)(5)Assumes that both power supplies fail simultaneouslyλ = Failure Rate = 1/MTBFTable 1.3ControlLogix Product Probability of Failure on Demand CalculationsFor PFD calculations with proof test intervals of 2 and 4 years, seeAppendix E.Publication 1756-RM001B-EN-P - October 2003

1-12 SIL PolicyCatalogNumberDescription1756-A-- ControlLogix Chassis 40,143,919 (2)Table 1.4ControlLogix Product Probability of Undetected Dangerous Failure per HourMean Time λ (5) Calculated PFH:Between Failure(MTBF) (1) 1oo1 architecture 1oo2 architecture(average (3) )2.49E-081.25E-091756-CNB ControlNet Bridge 3,596,087 (2) 2.78E-07 1.39E-081756-CNBR Redundant ControlNet Bridge 3,385,813 (2) 2.95E-07 1.48E-081756-IA16I AC Isolated Input 4,144,192 2.41E-07 1.74E-091756-IA8D AC Diagnostic Input 3,856,320 2.59E-07 1.87E-091756-IB16D DC Diagnostic Input 7,386,774 1.35E-07 9.63E-101756-IB16I DC Isolated Input 3,562,624 2.81E-07 2.03E-091756-IF8 Analog Input 1,690,694 5.91E-07 4.44E-091756-IR6I RTD Input 3,456,960 2.89E-07 2.10E-091756-IT6I Thermocouple Input 4,784,000 2.09E-07 1.50E-091756-L55M16 ControlLogix 5555 Processor 2,855,348 (2) 3.50E-07 1.75E-081756-OA16I AC Isolated Output 1,994,720 5.01E-07 3.72E-091756-OA8D AC Diagnostic Output 3,839,680 2.60E-07 1.30E-081756-OB16D DC Diagnostic Output 4,520,534 2.21E-07 1.11E-081756-OB16I DC Isolated Output 1,703,520 5.87E-07 4.40E-091756-OB8EI DC Fused Output 1,239,680 8.07E-07 6.20E-091756-OF8 Analog Output 2,054,694 4.87E-07 3.61E-091756-OX8I Contact Output 6,639,360 1.51E-07 1.07E-091756-PA75 AC Power Supply 7,301,935 (2) 1.37E-07 6.85E-091756-PA75R AC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 1.14E-111756-PB75 DC Power Supply 7,100,760 (2) 1.41E-07 7.04E-091756-PB75R DC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 1.14E-111756-PSCA Power Supply Chassis Adapter 45,146,727 (2) 2.21E-08 1.11E-09(1) MTBF measured in hours.(2) Calculated using field-based values for components.(3) Average = The arithmetic average of the MTBFs of all five Chassis (1756-A4, A7, A10, A13, and A17)(4)(5)Assumes that both power supplies fail simultaneously.λ = Failure Rate = 1/MTBFPublication 1756-RM001B-EN-P - October 2003

SIL Policy 1-13Table 1.5 shows an example of a PFD calculation for a safety loopinvolving two DC input modules used in a 1oo2 configuration and aDC output module.Table 1.5Catalog Number: Description: MTBF: Calculated PFD:1756-Axx ControlLogix Chassis 40,143,900 5.58E-06(average)1756-L55M16 ControlLogix 5555 2,855,348 7.84E-05Controller1756-OB16D DC Output 4,520,534 4.96E-051756-IB16D DC Diagnostic Input 7,386,774 2.40E-06Total PFD calculation for a safety loop consisting of these products: 1.36E-04This example is shown graphically in the first loop shown inFigure 1.3 on page 1-14.Publication 1756-RM001B-EN-P - October 2003

1-14 SIL PolicySIL ComplianceDistribution and WeightThe programmable controller may conservatively be assumed tocontribute 10% of the reliability burden. (See Figure 1.3.) A SIL 2system may need to incorporate multiple inputs for critical sensorsand input devices, as well as dual outputs connected in series to dualactuators dependent on SIL assessments for the safety related system.(See Figure 1.3)Figure 1.3 ControlLogix Systems or Loop+V10% of the PFD40% ofthe PFDSensorInputModulePowerSupplyControllerDiag.OutputModuleActuator50% of the PFDSensorInputModule43383+V10% of the PFD40% ofthe PFDSensorInputModulePowerSupplyControllerStandardOutputModuleActuator50% of the PFDSensorInputModuleMonitoringInputModule43384Publication 1756-RM001B-EN-P - October 2003

SIL Policy 1-15Agency CertificationsUser documentation shipped with ControlLogix products typically listthe agency certifications for which the products are approved. If aproduct has achieved agency certification, it is marked as such on theproduct labeling. Product certifications are listed in the product’sspecifications table, as shown in the example below.Certification UL UL Listed Industrial Control EquipmentCSAFMCECSA Certified Process Control Equipment for Class I, Division2 Group A,B,C,D Hazardous LocationsFM Approved Equipment for use in Class I Division 2 GroupA,B,C,D Hazardous LocationsEuropean Union 89/336/EEC EMC Directive, compliant with:EN 50081-2; Industrial EmissionsC-TickAustralian Radio Communications Act, compliant with:AS/NZS 2064; Industrial EmissionsResponse TimesThe response time of the system is defined as the amount of time ittakes for a change in an input condition to be recognized andprocessed by the controller’s ladder logic program, and then to initiatethe appropriate output signal to an actuator. The system response timeis the sum of the following:• input hardware delays• input filtering• I/O and communication module RPI settings• controller program scan times• output module propagation delaysEach of the times listed above is variably dependent on factors such asthe type of I/O module and instructions used in the ladder program.For examples of how to perform these calculations, see Appendix A,Response Times in ControlLogix.For more information on the available instructions and for a fulldescription of logic operation and execution, see the followingpublications:• Logix5000 Controllers General Instruction Set Reference Manual,publication 1756-RM003.• ControlLogix System User Manual, publication 1756-UM001.These publications are available from Rockwell Automation.Publication 1756-RM001B-EN-P - October 2003

1-16 SIL PolicyProgram Watchdog Time inControlLogix SystemThe program watchdog (also known as the software watchdog) timeis a user-defined time that is set in the controller attributes menu ofthe RSLogix 5000 software. See the ControlLogix System User Manual,publication number 1756-UM001 for more information. Thepublication is available from Rockwell Automation.The program watchdog time is the maximum permissible timeallowed for a RUN cycle (cycle time). If the cycle time exceeds theprogram watchdog time, a major fault occurs on the controller. Usersmust monitor the watchdog and program the system outputs totransition to the safe state (typically the OFF state) in the event of amajor fault occurring on the controller. For more information onfaults, see Chapter 7, Faults in the ControlLogix System.The program watchdog time must be ≥ 10 ms and must be < 50% ofthe safety time required for a ControlLogix system. The safety time isthe maximum amount of time in which the process tolerates a wrongsignal.Contact Information WhenDevice Failure OccursWhen users experience a failure with any SIL2-certified ControlLogixdevice, they should contact their local Rockwell Automation salesoffice. With this contact, the user can:• return the device to Rockwell Automation so the failure isappropriately logged for the catalog number affected and arecord made of the failure.• request a failure analysis (if necessary) to determine the cause ofthe failure, if possible.Publication 1756-RM001B-EN-P - October 2003

Chapter 2The ControlLogix SystemThis chapter offers an overview of some standard features in theControlLogix architecture that assist in its suitability for use in SIL2applications.For information about:See page:General Overview of ControlLogix Platform 2-1Overview of the ControlLogix Architecture 2-2Module Fault Reporting 2-3Fault Handling 2-3Data Echo Communication Check 2-4Pulse Test 2-5Software 2-6Communications 2-6Other Unique Features that Aid Diagnostics 2-7General Overview ofControlLogix PlatformMany of the diagnostic methods and techniques used in theControlLogix platform are improved versions of techniques anddesigns previously incorporated into Allen-Bradley PLC platforms overthe last three decades.These are designs that have evolved to maintain the robustness anddeterministic response that our customers have come to expect asthey migrated from electromechanical to solid state technology.The self-checking routines and diagnostics performed bymicroprocessor-based systems (for example, ControlLogix) havegreatly advanced over the years. Programmable controllers such asControlLogix can be programmed and configured to perform checkson the total system, including its own configuration, wiring, andperformance, as well as monitor input sensors and output devices.1 Publication 1756-RM001B-EN-P - October 2003

2-2 The ControlLogix SystemIf an anomaly (other than automatic shutdown) is detected, the systemcan be programmed to initiate user-defined fault handling routines.Output modules can turn OFF selected outputs in the event of afailure. New diagnostic I/O modules self-test to make sure that fieldwiring is functioning. Output modules use pulse testing to make sureoutput switching devices are not shorted. Using these internalfeatures, as well as application software when needed, today’sControlLogix customers are able to achieve highly reliable controlsystems.Overview of theControlLogix ArchitectureRockwell Automation’s latest generation of programmable controllersis the ControlLogix system. Inherent in its design and implementationare several features that surpass anything offered in previous productarchitectures. The inclusion of these features represent improvementsdriven by customer demand for uptime and reliability as well asRockwell’s long-developed design experience in producing thesetypes of products.One of the most significant changes in the architecture is theimplementation of the Producer/Consumer (P/C) communicationmodel between controller and I/O. The P/C communication modelreplaces traditional ‘polling’ of I/O modules and, consequently, haschanged the overall behavior of these components vis-a-vis theircounterparts in previous architectures. Input modules “produce” data,controller and output modules both “produce” and “consume” data.These changes were embraced because of the enhanced data integrityand fault reporting capabilities they provide. I/O modules nowexchange much more than simply the ON/OFF state of the devicesthey are connected to. Module identification information,communication status, fault codes and, through the use ofspecially-designed modules, field-side diagnostics can now all beretrieved from the I/O system as part of the standard feature set of theProducer/Consumer communication model. (See Figure 2.1).Figure 2.1Producer/Consumer Communication ModelLogix ControllerInput ModulesOutput ModulesCommonly Shared Data43374Publication 1756-RM001B-EN-P - October 2003

The ControlLogix System 2-3Module Fault ReportingOne of the key concepts in this model is Ownership. Every module inthe control system is now “owned” by at least one controller in thearchitecture. When a controller “owns” an I/O module, it means thatthat controller stores the module’s configuration data, defined by theuser; this data dictates how the module behaves in the system.Inherent in this configuration and ownership is the establishment of a“heartbeat” between the controller and module; this heartbeat is alsoknown as the Requested Packet Interval (RPI).The existence of the RPI forms the basis for Module Level Faultreporting in the ControlLogix architecture, a capability which isinherent to all ControlLogix I/O modules.For more information on module fault reporting in the ControlLogixcontroller, specifically the GSV instructions, see Chapter 7, Faults inthe ControlLogix System.Fault HandlingThe RPI defines a minimum time interval in which the controller andI/O module must communicate with each other. If, for any reason,communications cannot be established or maintained (that is, the I/Omodule has failed), the system can be programmed to run a specialFault Handling routine. This routine determines whether the systemmust continue functioning or whether the fault condition warrants ashutdown of the application.For example, the system can be programmed to retrieve the fault codeof the failed module and make a determination, based on the type offault, as to whether to continue operating. In addition, standardControlLogix output modules are also capable of reporting blown-fusestatus and loss of field power back to the controller.This ability of the controller to monitor the health of I/O modules inthe system and take appropriate action based on the severity of a faultcondition gives the user complete control of the application’s behaviorwhen trouble occurs. It is the user’s responsibility to establish thecourse of action appropriate to their safety application.For more information on Fault Handling, see Chapter 7, Faults in theControlLogix System.Publication 1756-RM001B-EN-P - October 2003

2-4 The ControlLogix SystemData Echo Communication CheckAnother powerful by-product of the p/c communication model andthe implementation of the Control and Information Protocol (CIP)protocol is the Output Data Echo, a communication methodemployed between owner-controllers and every output module in thesystem. Output Data Echo allows the user to verify that an ON/OFFoutput command from the controller was actually received by thecorrect output module, and that the module will attempt to executethe command to the field device connected to it.During normal operation, when a controller sends an outputcommand, the output module that is targeted for that command will“echo” that requested state back to the system upon its receipt. Thisverifies that the module has received the command and will try toexecute it. By comparing the requested state from the controller to theData Echo received from the module, the user can validate that thesignal has reached the correct module and that the module willattempt to activate the appropriate field-side device. Again, it is theuser’s responsibility to establish the course of action appropriate totheir safety application.When used with standard ControlLogix output modules, the DataEcho validates the command up to the system-side of the module, butnot to the field-side. However, when this feature is used in tandemwith diagnostic output modules, the user can virtually verify theoutput command integrity from the controller to the actuatorconnected to the module.Diagnostic output modules contain special circuitry that performsField Side Output Verification. Field Side Output Verificationinforms the user that system-side commands received by the moduleare accurately represented on the power side of the switching device.In other words, for each output point, this feature confirms that theoutput is ON when it is commanded to be ON or OFF whencommanded to be OFF.The capability of comparing the actual state of the field-side of thediagnostic module’s output against what the controller commandsgives the user the ability to make sure that the module is performingwhat the control system is requesting, once that output command hasbeen issued.Publication 1756-RM001B-EN-P - October 2003

The ControlLogix System 2-5Figure 2.2 Output Module Behavior in the ControlLogix SystemOutput Commands from ControllerStandardControlLogix I/OInformationData Echo validation from system-sideAdditional Field-SideInformation provided byDiagnostic Output modulesField-side Output Verification, PulseTest status plus No Load detectionActuatorPulse TestA diagnostic output module feature called a Pulse Test can verifyoutput circuit functionality without actually changing the state of theactuator connected to the output. Under user program control, anextremely short-duration pulse is directed to a particular output on themodule. The output circuitry will momentarily change its current statelong enough to verify that it CAN change state when requested, butshort enough in duration (the actual pulse is measured inmilliseconds) not to effect the actuator connected to the output. Thispowerful feature allows a user to perform a preemptive diagnosis ofpossible future module conditions before they occur.Publication 1756-RM001B-EN-P - October 2003

2-6 The ControlLogix SystemSoftwareThe location, ownership and configuration of I/O modules andcontrollers is performed using RSLogix 5000 programming software(version 10). The software is used for creation, testing and debuggingof application logic.When using RSLogix 5000, users must remember the following:• During normal SIL2-certified operation:– we recommend the programming terminal be disconnected.– the keyswich must be set to the RUN position.– the controller key must be removed from the keyswitch.• Authorized personnel may change an application program butonly by using one of the processes described in sectionChanging Your Application Program on page 9-6.CommunicationsControlNet forms the basis for I/O communications on theControlLogix backplane and over the network. It is anindustry-proven network that incorporates 16-bit CRC and a standardCIP network protocol. You must use RSNetWorx for ControlNetsoftware to schedule the network. The correct scheduling of thenetwork is independently verified by the controller after the programis downloaded; the schedule must match the RSLogix 5000 program.The software also provides user-defined fault handing (for example,execute fault routine) in the case of errors.A serial port is available on the controller for download orvisualization only. It uses an industry-proven DF-1 serial link protocolthat has a selection of either 8-bit BCC checksum or 16-bit CRC. Theserial port also uses an industry standard CIP network protocolrunning on the DF-1 link.EtherNet/IP connection is also available for download, monitoring andvisualization.Publication 1756-RM001B-EN-P - October 2003

The ControlLogix System 2-7Other Unique Features that Aid DiagnosticsThese are just a few examples of how the inherent characteristics ofthe ControlLogix I/O system provides the user with an unprecedentedcapability to diagnose and react to fault conditions in an application.There are many other unique features that differentiate it fromprevious iterations of programmable controllers, such as:• Timestamping of I/O and diagnostic data• Electronic keying based on module identificationFor more information on these features, see the Digital I/O usermanual, publication number 1756-UM058.Checklist for theControlLogix SystemThe following checklist is required for planning, programming andstart up of a SIL2-certified ControlLogix system. It may be used as aplanning guide as well as during proof testing. If used as a planningguide, the checklist can be saved as a record of the plan.Check List for ControlLogix System (1)Company:Site:Loopdefinition:No. Fulfilled Comment1 Are you only using the SIL2-certified ControlLogix modules listed in Table 1.1 onpage 1-6, with the corresponding firmware release listed in the table, for yoursafety application?2 Have you calculated the system’s response time?3 Does the system’s response time include both the user-defined, SIL-task programwatchdog (software watchdog) time and the SIL-task duration time?4 Is the system response time in proper relation to the process tolerance time?5 Have PFD values been calculated according to the system’s configuration?6 Have you performed all appropriate proof tests?7 Have you defined your process parameters that are monitored by fault routines?8 Have you determined how your system will handle faults?9 Are you using version 10 of RSLogix 5000, the ControlLogix system programmingsoftware?10 Have you taken into consideration the checklists for using SIL inputs and outputslisted on pages 6-25 and 6-26.YesNo(1)For more information on the specific tasks in this checklist, see the previous sections in the chapter or Chapter 1, SIL Policy.Publication 1756-RM001B-EN-P - October 2003

2-8 The ControlLogix SystemNotes:Publication 1756-RM001B-EN-P - October 2003

Chapter 3ControlLogix System HardwareThis chapter discusses the hardware required in SIL2-certifiedControlLogix systems.For information about:See page:Introduction to the Hardware 3-1ControlLogix Chassis 3-2ControlLogix Power Supplies 3-2Non-Redundant Power Supply 3-3Redundant Power Supply 3-3Recommendations for System Hardware Use 3-4Related ControlLogix Hardware Documentation 3-5Introduction to theHardwareSIL2-certified ControlLogix systems can use the following chassis andpower supply hardware:• ControlLogix Chassis - Including the following catalog numbers:– 1756-A4– 1756-A7– 1756-A10– 1756-A13– 1756-A17• ControlLogix Power Supplies - Including the followingcatalog numbers:– 1756-PA75– 1756-PB75– 1756-PA75R– 1756-PB75R– 1756-PSCA– 1756-CPR cables1 Publication 1756-RM001B-EN-P - October 2003

3-2 ControlLogix System HardwareControlLogix ChassisThe ControlLogix 1756-Axx chassis provide the physical connectionsbetween modules and the ControlLogix backplane. These connectionsallow for P/C communications between controllers and I/O modules.The chassis itself is passive and is not relevant to further discussionsince any physical failure would be unlikely under normalenvironmental conditions and would be manifested and detected as afailure within one or more of the active components.ControlLogix PowerSuppliesControlLogix power supplies are designed with noise filtering andisolation to reduce the opportunity for induced contamination of thesupplied voltages. The power supply monitors the backplane powerand generates control signals (for example, DC_FAIL_L) to indicate ifpower failure is imminent. Anomalies in the supplied voltagesimmediately shut down the power supply. The power supplymonitors all power supply voltages via sense lines.IMPORTANTNo extra configuration or wiring is required for SIL2operation of the ControlLogix power supplies.All ControlLogix power supplies are designed to:• detect anomalies• communicate to the controllers with enough stored power toallow for an orderly and deterministic shutdown of the system,including the controller and I/OPublication 1756-RM001B-EN-P - October 2003

ControlLogix System Hardware 3-3Non-Redundant Power SupplyControlLogix non-redundant power supplies (i.e one power supply isconnected to a chassis) certified for use in SIL2 applications includethe following catalog numbers:• 1756-PA75 - AC power supply• 1756-PB75 - DC power supplyRedundant Power SupplyControlLogix redundant power supplies (i.e two power supplies areconnected to the same chassis) certified for use in SIL2 applicationsinclude the following catalog numbers:• 1756-PA75R - AC power supply• 1756-PB75R - DC power supply• 1756-PSCA - Redundant power supply chassis adapter modulerequired with the use of redundant power supplies• 1756-CPR cablesThe power supplies share the current load required by the chassis andan internal solid state relay that can annunciate a fault. Upon detectionof a failure in one supply, the other redundant power supplyautomatically assumes the full current load required by the chassiswithout disruption to devices installed.The 1756-PSCA redundant power supply chassis adapter moduleconnects the redundant power supply to the chassis.For additional ControlLogix power supply information, see thedocumentation referenced in the Related ControlLogix HardwareDocumentation section on page 3-5.Publication 1756-RM001B-EN-P - October 2003

3-4 ControlLogix System HardwareRecommendations forSystem Hardware UseUsers must consider the recommendations listed below when usingSIL2-certified ControlLogix hardware:ChassisWhen installing ControlLogix chassis, follow the information providedin the product documentation listed in the Related ControlLogixHardware Documentation section on page 3-5.Power SuppliesUsers must consider these recommendations when using SIL2-certifiedControlLogix power supplies:• When installing ControlLogix power supplies, follow theinformation provided in the product documentation listed in theRelated ControlLogix Hardware Documentation section onpage 3-5.• A non-redundant power supply can be used if it meets theuser-defined PFD criteria.• For high availability SIL2 applications, the redundant powersupply is recommended.• It is recommended that the solid state fault relay on each powersupply be wired from an appropriate voltage source to an inputpoint in ControlLogix so the user can detect and display a powersupply fault.Publication 1756-RM001B-EN-P - October 2003

ControlLogix System Hardware 3-5Related ControlLogixHardware DocumentationFor more information on ControlLogix hardware, see the followingRockwell Automation publications:• ControlLogix Chassis Installation Instructions, publication1756-IN080• ControlLogix Non-Redundant Power Supplies InstallationInstructions, publication 1756-5.78• ControlLogix Redundant Power Supplies InstallationInstructions, publication 1756-IN573• ControlLogix Redundant Power Supply Chassis Adapter ModuleInstallation Instructions, publication 1756-IN574These publications are available from Rockwell Automation byvisiting:http://www.theautomationbookstore.comhttp://www.ab.com/manualsPublication 1756-RM001B-EN-P - October 2003

3-6 ControlLogix System HardwareNotes:Publication 1756-RM001B-EN-P - October 2003

Chapter 4ControlLogix ControllerThis chapter discusses the ControlLogix controller as used in aSIL2-certified system.Introduction to theControllerThe ControlLogix controller (catalog number 1756-L55M16) used in aSIL2-certified ControlLogix system is a solid-state control system with auser-programmable memory for storage of data to implement specificfunctions, such as:• I/O control• Logic• Timing• Counting• Report generation• Communications• Arithmetic• Data file manipulationThe controller consists of a central processor, I/O interface andmemory.The controller performs power-up and run-time functional tests. Thetests are used with user-supplied application programs to verifyproper controller operation.1 Publication 1756-RM001B-EN-P - October 2003

4-2 ControlLogix ControllerRecommendations forController UseUsers must consider the recommendations listed below when using aSIL2-certified ControlLogix controller:• Use only one controller in SIL2-certified ControlLogix loop. Thecontroller must own the configuration information for all I/Omodules associated with the safety loop.• When installing ControlLogix controller, follow the informationprovided in the documentation listed in the Related ControllerDocumentation section below.Related ControllerDocumentationFor more information on the ControlLogix controller, see thefollowing Rockwell Automation publications:• ControlLogix Controller Installation Instructions, publication1756-IN101• ControlLogix System User Manual, publicationThese publications are available from Rockwell Automation byvisiting:http://www.theautomationbookstore.comhttp://www.ab.com/manualsPublication 1756-RM001B-EN-P - October 2003

Chapter 5ControlLogix Communications ModulesThis chapter discusses the communication modules used in aControlLogix SIL2 system.For information about:See page:Introduction to Communication Modules 5-1ControlNet Bridge Module 5-2ControlNet Cabling 5-2ControlNet Module Diagnostic Coverage 5-2Ethernet Module 5-2Ethernet Versus ControlNet 5-2Related Communications Modules5-4DocumentationIntroduction toCommunication ModulesThe communications modules in a SIL2-certified ControlLogix systemprovide communication bridges from a ControlLogix chassis to otherchassis or devices via the ControlNet and Ethernet networks. Thefollowing communications modules are available:• ControlNet modules - Catalog numbers 1756-CNB & 1756-CNBR• Ethernet modules - Catalog number 1756-ENBTControlLogix communications modules can be used in peer-to-peercommunications between ControlLogix devices. The communicationsmodules can also be used for expansion of I/O to additionalControlLogix remote I/O chassis.1 Publication 1756-RM001B-EN-P - October 2003

5-2 ControlLogix Communications ModulesControlNet Bridge ModuleThe ControlNet bridge module (1756-CNB & 1756-CNBR) provides forthe communications between ControlLogix chassis over theControlNet network.ControlNet CablingFor remote racks, a single RG6 coax cable is required for ControlNet.Although it is not a requirement to use redundant media with the1756-CNBR, it does provide higher system reliability. Redundantmedia is not required for SIL2 operation.ControlNet Module Diagnostic CoverageAll communications over the passive ControlNet media occur via CIP,which guarantees delivery of the data. All modules independentlyverify proper transmission of the data.Ethernet ModuleThe Ethernet bridge module (1756-ENBT) provides for thecommunications from one ControlLogix chassis to other devices overthe Ethernet network.The Ethernet link is based on industry-standard CIP network protocolrunning on top of TCP and UDP using 32-bit CRC. Also, TCP and UDPwith 16-bit Checksums are running on top of Ethernet.Ethernet Versus ControlNetAlthough it may be acceptable to use Ethernet for specificapplications, such as program download, Ethernet requires a switchfor a “star” configuration. Rockwell Automation does not sell orreference a SIL2/SIL3 Ethernet switch. Also Ethernet is an “active”media whereas ControlNet uses a “passive” media (that is, very lowfailure rate).Publication 1756-RM001B-EN-P - October 2003

ControlLogix Communications Modules 5-3Recommendations forCommunications ModulesUseUsers must consider the recommendations listed below when usingSIL2-certified communications modules:• When installing ControlLogix communications modules, followthe information provided in the documentation listed in theRelated Communications Modules Documentation section onpage 5-4.• Use Ethernet for communications to Human-to-MachineInterfaces (HMI) and programming terminals only. For moreinformation on using HMI, see Figure 1.2 on page 1-4 andChapter 10, Use and Application of Human to MachineInterfaces.• Remote I/O chassis should be connected via ControlNet only.• Peer-to-peer communication is restricted to ControlNet only andshould occur only if the controller in the safety loop is sharingits own information (for example, via produced tags) with othercontrollers outside the loop.• For exchanging I/O data, use listen-only connections.• For exchanging non-I/O data, use producer/consumer tags.• Typically, no devices must be permitted to write data to thecontroller in the safety loop. The only exception to thisrecommendation is the use of HMI devices. For moreinformation on how to use HMI in the safety loop,see Chapter 10.For more information on connecting remote I/O chassis andpeer-to-peer communication, see Figure 1.2 on page 1-4.Publication 1756-RM001B-EN-P - October 2003

5-4 ControlLogix Communications ModulesRelated CommunicationsModules DocumentationFor more information on ControlLogix communications modules, seethe following Rockwell Automation publications:• ControlLogix Non-Redundant and Redundant ControlNetInterface Modules Installation Instructions, publication 1756-571• ControlLogix Non-Redundant and Redundant ControlNetInterface Modules User Manual, publication 1756-6.5.3• ControlLogix Ethernet Communication Module InstallationInstructions, publication 1756-IN019• ControlLogix Ethernet Communication Module User Manual,publication 1756-UM050These publications are available from Rockwell Automation byvisiting:http://www.theautomationbookstore.comhttp://www.ab.com/manualsPublication 1756-RM001B-EN-P - October 2003

Chapter 6ControlLogix I/O ModulesThis chapter discusses the ControlLogix I/O modules that are SIL2certified.For information about:See page:Overview of ControlLogix I/O Modules 6-1Module Fault Reporting for any ControlLogix I/O 6-4ModuleUsing Digital Input Modules 6-4Wiring ControlLogix Digital Input Modules 6-6Using Digital Output Modules 6-7Wiring ControlLogix Digital Output Modules 6-10Using Analog Input Modules 6-13Wiring ControlLogix Analog Input Modules 6-16Checklist for SIL Inputs 6-25Checklist for SIL Outputs 6-26Overview of ControlLogixI/O ModulesIn the most basic description, there are two types of SIL2-certifiedControlLogix I/O modules:• Digital I/O modules• Analog I/O modulesWith each type, however, there are differences between specificmodules. Because the differences propagate to varying levels in eachmodule type, a graphical representation can best provide an overviewof the many SIL2-certified ControlLogix I/O modules.1 Publication 1756-RM001B-EN-P - October 2003

6-2 ControlLogix I/O ModulesFigure 6.1 shows the SIL2-certified ControlLogix I/O modules. Eachtype, digital or analog, is described in greater detail throughout therest of this chapter.Figure 6.143372ControlLogix I/O modules are designed with inherent features thatassist them in complying with the requirements of the 61508 Standard.For example, the modules all have a common backplane interfaceASIC, execute power-up and runtime diagnostics, offer electronickeying and offer producer-consumer communication.Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-3Table 6.1 ControlLogix I/O Modules For Use in the SIL 2 SystemFor SIL2 compliance when installing ControlLogix I/O modules,follow the information provided in the documentation listed inTable 6.1.Table 6.1 lists the ControlLogix I/O modules initially submitted forSIL2 certification and shown in Figure 6.1.Related Documentation (1) with MoreCatalogInformation on Catalog Number:Module Type: Number:Description:Installation Instructions: User Manual:Digital 1756-IA16I AC Isolated Input Module 1756-IN059 1756-UM0581756-IA8D AC Diagnostic Input Module 1756-IN0551756-IB16D DC Diagnostic Input Module 1756-IN0691756-IB16I DC Isolated Input Module 1756-IN0101756-OA16I AC Isolated Output Module 1756-IN0091756-OA8D AC Diagnostic Input Module 1756-IN0571756-OB16D DC Diagnostic Output Module 1756-IN0581756-OB16I DC Isolated Output Module 1756-IN5121756-OB8EI DC Isolated Output Module 1756-IN0121756-OX8I Isolated Relay Output Module 1756-IN513Analog 1756-IF8 Analog Input Module 1756-IN040 1756-6.5.91756-IR6I RTD Input module 1756-IN0141756-IT6I Thermocouple Input module 1756-IN0371756-OF8 Analog Output Module 1756-5.41(1) These publications are available from Rockwell Automation by visiting http://www.theautomationbookstore.com or http://www.ab.com/manuals.Publication 1756-RM001B-EN-P - October 2003

6-4 ControlLogix I/O ModulesModule Fault Reporting forany ControlLogix I/OModuleUsers must make sure that all ControlLogix I/O modules are operatingproperly in the system. If the modules are not operating properly, theuser must initiate a fault routine when a fault occurs. This can beaccomplished in ladder logic through the use of the Get System Valueinstruction (GSV) and an examination of the MODULE object’s ’EntryStatus’ attribute for a running condition.An example of how this might be done is shown in Figure 6.2. Thismethod, or something similar, must be used to interrogate the healthof each I/O module in the system.Figure 6.2 Example of Checking a Module’s Health in Ladder LogicGSVObtain MODULEObject’s Entry StatusANDMask Off Lower 12Bits of ValueNEQCheck Entry Status tomake sure module isrunningFaultFor more information on the GSV instruction and MODULE Objects,see Chapter 7, Faults in the ControlLogix System. For moreinformation on creating Fault Routines, see Appendix B, SystemSelf-Testing and User-Programmed Responses.Using DigitalInput ModulesControlLogix digital input modules are divided into two categories:• Diagnostic input modules• Standard input modulesThese modules share many of the same inherent architecturalcharacteristics. However, the diagnostic input modules incorporatefeatures that allow diagnosing of field-side failures. These featuresinclude broken wire (that is, wire-off) detection and, in the case of ACDiagnostic modules, loss of line power.Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-5Table 6.2 lists the digital input modules that are suitable for use inSIL2 applications.Table 6.2 ControlLogix Digital Input Modules Suitable for SIL2 ApplicationsModule Type: Catalog Number: Description:Diagnostic Input Modules 1756-IB16D DC Diagnostic Input Module1756-IA8DAC Diagnostic Input ModuleStandard Input Modules 1756-IB16I DC Isolated Input Module1756-IA16IAC Isolated Input ModuleGeneral Considerations when using Any ControlLogix DigitalInput ModuleRegardless of the type of ControlLogix input module used, there are anumber of general application considerations that users must followwhen applying these modules in a SIL2 application:• Proof Tests - Periodically (for example, once every severalyears) a System Validation test must be performed. Manually, orautomatically, test inputs to make sure that all inputs areoperational and not stuck in the ON or OFF state. Inputs mustbe cycled from ON to OFF or OFF to ON. For additionalinformation on Proof Tests, see page 1-5 and Figure 9.1 onpage 9-5.• Always use a direct connection with diagnostic input moduleslocated in remote chassis.• Wire sensors to separate input points on two separate modules.• Configuration parameters (for example, RPI, filter values) mustbe identical between the two modules.• The same controller must own both modules.For operational state information, see Chapter 1, SIL Policy.Publication 1756-RM001B-EN-P - October 2003

6-6 ControlLogix I/O ModulesWiring ControlLogix DigitalInput ModulesThe wiring diagrams in Figure 6.3 show two methods of wiring thedigital input Module. In either case, users must determine whetherthe use of 1 or 2 sensors is appropriate to fulfill SIL2 requirements.Figure 6.3 ControlLogix Digital Input Module Wiring+ LineOne-Sensor Wiring ExampleInput A1Input B1SensorOptional Relaycontact toswitch linevoltage forperiodicautomatedtestingInput A2Input B2Two-Sensor Wiring ExampleSensorSensor43366Application logic can compare input values or states for concurrence.Figure 6.4Input AInput BActuatorThe user program must also contain rungs to annunciate a fault in theevent of a sustained miscompare between two points.Figure 6.5Input AInput BTimerInput ATimer DoneFaultInput BTimer preset in milliseconds tocompensate for filter time andhardware delay differences.FaultAlarm to OperatorThe control, diagnostics and alarming functions must be performed insequence. For more information on faults, see Chapter 7, Faults in theControlLogix System.Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-7Using Digital OutputModulesControlLogix digital output modules are divided into two categories:• Diagnostic output modules• Standard output modulesThese modules share many of the same inherent architecturalcharacteristics. However, the diagnostic output modules incorporatefeatures that allow diagnosing of field-side failures. These featuresinclude reporting No-Load conditions and point-level fuse-blown. Inaddition, the diagnostic modules can validate the state of the outputwith the Output Verify feature and the Output Pulse test.Table 6.3 lists the digital output modules that are suitable for use inSIL2 applications.Table 6.3 ControlLogix Digital Output Modules Suitable for SIL2 ApplicationsModule Type: Catalog Number: Description:Diagnostic Output Modules 1756-OB16D DC Diagnostic OutputModule1756-OA8DAC Diagnostic OutputModuleStandard Output Modules 1756-OB16I DC Isolated Output Module1756-OA16IAC Isolated Output Module1756-OB8EIDC Isolated Output Module1756-OX8IIsolated Relay OutputModulePublication 1756-RM001B-EN-P - October 2003

6-8 ControlLogix I/O ModulesGeneral Considerations when using Any ControlLogix DigitalOutput ModuleWiring the two types of digital output modules differs, depending onyour application requirements (these wiring methods are explained indetail in later sections). However, regardless of the type ofControlLogix output module used, there are a number of generalapplication considerations that you must follow when applying thesemodules in a SIL2 application:• Proof Tests - Periodically (for example, once every severalyears) a System Validation test must be performed. Manually, orautomatically, test outputs to make sure that all outputs areoperational and not stuck in the ON or OFF state. Outputs mustbe cycled from ON to OFF or OFF to ON. For additionalinformation on Proof Tests, see page 1-5 and Figure 9.1 onpage 9-5.• Examination of Output Data Echo signal in Applicationlogic: The application logic must examine the Data Echo valueassociated with each output point to make sure that therequested On/Off command from the controller was received bythe module.In the rungs below, a timer begins to increment for anymiscompare between the actual output bit and its associatedData Echo bit. The timer must be preset to accommodate thedelay between setting the output bit in controller memory andreceipt of the Data Echo from the module. If a miscompareexists for longer than that time, a fault is reported.Figure 6.6Application LogicActuatorOutput BitData EchoTimerOutput BitData EchoTimer doneFaultFaultAlarm to OperatorPublication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-9The control, diagnostics and alarming functions must beperformed in sequence. For more information on faults, seeChapter 7, Faults in the ControlLogix System.• Use of external Relays to disconnect Module Power ifOutput De-energization is Critical: To make sure outputs willde-energize, users must wire an external relay that can removepower from the output module if a short or other fault isdetected. See Figure 6.7 on page 6-10 for an example method ofwiring an external relay.• Test outputs at specific times to make sure they areoperating properly. The method and frequency of testing isdetermined by the type of module–diagnostic or standard. Formore information on testing diagnostic module outputs, seepage 6-10. For more information on testing standard moduleoutputs, see page 6-11.• For typical emergency shutdown (ESD) applicationsoutputs must be configured to De-energize: Whenconfiguring any ControlLogix output module, each output mustbe configured to de-energize in the event of a fault and in theevent of the controller going into program mode. For exceptionsto the typical ESD applications, see Chapter 1, SIL Policy.• When wiring two digital output modules in series so that onemay break source voltage (as shown in Figure 6.10 onpage 6-12), make sure:– Both modules use identical configuration.– The same controller owns both modules.Publication 1756-RM001B-EN-P - October 2003

6-10 ControlLogix I/O ModulesWiring ControlLogix DigitalOutput ModulesDiagnostic Digital Output ModulesDiagnostic output modules have advanced circuitry that is notincluded in standard output modules. Because of the advanceddesign, users are not required to use an input module to monitoroutput status, as is required with standard output modules.Diagnostic Output modules can be used as-is in a SIL2 application (inother words, no special wiring considerations need be employedother than the wiring of the external relay to remove line power fromthe module in the event of a fault to make sure outputs willde-energize if shorted).In addition to following the General Considerations when using AnyControlLogix Digital Output Module on page 6-8, the user mustperform a Pulse Test on each output periodically to make sure that theoutput is capable of changing state. Automatic diagnostic testing ofoutput modules should be made at intervals that are an order ofmagnitude less than the demand rate. For example, pulse testingshould be scheduled at least once a month for a low demandsystem and at least once hour for a high demand system.For more information on performing the pulse test, see theControlLogix Digital I/O Modules User Manual, publication1756-UM058.Users should also make sure they always use a direct connection withdiagnostic output modules located in remote chassis.Figure 6.7 ControlLogix Diagnostic Output Module WiringV-/L2V+/L2V+/L1This relay is controlled bythe rest of the ControlLogixsystem. If a short circuit orfault occurs on the module,the relay can disconnectpower to the module.OutputActuatorAlso, this relay can be wiredto disconnect power tomultiple modules.43365Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-11Standard Digital Output ModulesWhen using standard (also known as non-diagnostic) output modules,users must wire an output to an actuator and then back to an input tomonitor the output’s performance. The user can write the appropriatelogic to test the output’s ability to turn ON and OFF at power-up, or,at the proof test interval (see page 1-5), the user can force the outputON and OFF and use a voltmeter to verify output performance.Automatic testing of output modules (i.e. the user turns the outputsON and OFF to verify proper operation) should be made at intervalsthat are an order of magnitude less than the demand rate. Forexample, output testing should be scheduled at least once a monthfor a low demand system and at least once an hour for a highdemand system.In addition to following the General Considerations when using AnyControlLogix Digital Output Module on page 6-8, the user must wireeach standard output to a corresponding input to validate that theoutput is following its commanded state.Figure 6.8 ControlLogix Standard Output Module WiringStandard IsolatedOutput ModuleStandard IsolatedInput ModuleV-/L2V+/L1V+/L1Wire output pointto input point toverify the correctstate of the outputInputThis relay is controlled by anotheroutput in the ControlLogix system. If ashort circuit or fault occurs on outputmodules, the relay can disconnectpower to the modules.OutputActuatorV-/L2Also, this relay can be wired todisconnect power to multiple modules.43363Publication 1756-RM001B-EN-P - October 2003

6-12 ControlLogix I/O ModulesApplication logic must be written to generate a fault in the event of amiscompare between the requested state of an output (echo) and theactual output state monitored by an input channel.Figure 6.9Application LogicOutput FaultActuatorData EchoData EchoMonitoring InputMonitoring InputTimerTimer must be presetin milliseconds toaccommodatecommunication timesof echo signal andfilter time of input.Timer doneFaultFaultAlarm to OperatorThe control, diagnostics and alarming functions must be performed insequence. For more information on faults, see Chapter 7, Faults in theControlLogix System.Users can also wire two isolated standard outputs in series to criticalactuators. In the event that a failure is detected, the output from bothoutput modules must be set to OFF to guarantee the Output Loadsde-energize. Figure 6.10 shows how to wire two isolated standardoutputs in series to critical actuators.Figure 6.10 ControlLogix Standard Output Module Wiring With Two ModulesStandard IsolatedOutput Module #1Standard IsolatedOutput Module #2Standard IsolatedInput ModuleV-/L2V+/L1V+/L1V+/L1Wire output pointto input point toverify the correctstate of the outputInputOutputOutputActuatorV-/L243364Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-13Using Analog InputModulesThree ControlLogix analog input modules are certified for use SIL2applications. Table 6.4 lists the modules.Table 6.4 ControlLogix Analog Input Modules Suitable for SIL2 ApplicationsCatalog Number:1756-IF81756-IR6I1756-IT6IDescription:Single-ended analog input moduleIsolated RTD analog input moduleThermocouple/mV analog input moduleGeneral Considerations when using Any ControlLogix AnalogInput ModuleThere are a number of general application considerations that youmust follow when applying these modules in a SIL2 application:• Proof Tests - Periodically (for example, once every severalyears) a System Validation test must be performed. Manually, orautomatically, test inputs to make sure that all inputs areoperational. Field signal levels should be varied over the fulloperating range to make sure that the corresponding channeldata varies accordingly. For additional information on ProofTests, see page 1-5 and Figure 9.1 on page 9-5.• Calibrate Inputs Periodically, As Necessary: ControlLogixI/O modules ship from the factory with a highly accurate levelof calibration. However, because each application is different,users are responsible for making sure their ControlLogix I/Omodules are properly calibrated for their specific application.Users can employ tests in application program logic todetermine when a module requires recalibration. For example,to determine whether an input module needs to be recalibrated,a user can determine a tolerance band of accuracy for a specificapplication. The user can then measure input values on multiplechannels and compare those values to acceptable values withinthe tolerance band. Based on the differences in the comparison,the user could then determine whether recalibration isnecessary.Calibration (and subsequent recalibration) is not a safety issue.However, we recommend that each analog input be calibrated atleast every 3 years to verify the accuracy of the input signal andavoid nuisance application shutdowns.Publication 1756-RM001B-EN-P - October 2003

6-14 ControlLogix I/O Modules• Choose Floating Point Data Format During ModuleConfiguration: ControlLogix analog input modules perform ahost of on-board alarm processing to validate that the inputsignal is within the proper range for the application. However,these features are only available in Floating Point mode.• Examine the Appropriate Module Fault, Channel Fault andChannel Status Bits to Initiate Fault Routines: Each modulewill communicate the operating status of each channel to thecontroller during normal operation. Application logic mustexamine the appropriate bits to initiate a fault routine for a givenapplication. For more information on faults, see Chapter 7,Faults in the ControlLogix System.• Compare Analog Input Data and Annunciate Miscompares:When wiring sensors to two inputs channels, the values fromthose channels must be compared to each other for concurrencewithin an acceptable range for the application before actuatingan output. Any miscompare between the two inputs outside theprogrammed acceptable range must be annunciated as a fault.In Figure 6.11, a user-defined percentage of acceptabledeviation (that is, tolerance) is applied to the configured inputrange of the analog inputs (that is, range) and the result is stored(that is, delta). This delta value is then added to and subtractedfrom one of the input channels; the results define an acceptableHigh and Low limit of deviation. The second input channel isthen compared to these limits to determine if the input areworking properly.The input’s OK bit preconditions a Timer run that is preset toaccommodate an acceptable fault response time and anycommunication filtering lags in the system. If the inputsmiscompare for longer than the preset value, a fault is registeredwith a corresponding alarm.Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-15Figure 6.11Inputs OKTimerMULTRangeTolerance %DeltaADDDeltaInput 1High LimitSUBDeltaInput 1Low LimitLIMLow LimitInput 2High LimitInputs OKTimer doneInputs FaultedInputs FaultedAlarm to OperatorThe control, diagnostics and alarming functions must beperformed in sequence. For more information on faults, seeChapter 7, Faults in the ControlLogix System.• Configuration parameters (for example, RPI, filter values) mustbe identical between the two modules.• The same controller must own both modules.Publication 1756-RM001B-EN-P - October 2003

6-16 ControlLogix I/O ModulesWiring ControlLogix AnalogInput ModulesIn general, good design practice dictates that each transmitter must bewired to separate input terminals on separate modules such that thechannel values may be validated by comparing the two within anacceptable range. Special consideration must be given in applying thistechnique, depending on the type of module being used. Thosedetails are shown in the following wiring diagrams.Wiring the Single-Ended Input Module in Voltage ModeIn addition to following the General Considerations when using AnyControlLogix Analog Input Module on page 6-13, make sure you usethe correct documentation (listed in Table 6.1 on page 6-3) to wire themodule.When operating in Single-ended voltage mode, all (-) leads of thetransmitters must be tied together. Figure 6.12 shows how to wire the1756-IF8 module for use in voltage mode.Figure 6.12 ControlLogix Analog Input Module Wiring in Voltage ModeCh0 +Ch0 +Ch0 – Ch0 –(+)(–)VoltageTransmitter A(+)(–)VoltageTransmitter B43368Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-17Wiring the Single-Ended Input Module in Current ModeIn addition to following the General Considerations when using AnyControlLogix Analog Input Module on page 6-13, before wiring themodule, consider the following application guideline:• Placement of Other Devices in Current Loop: you can locateother devices in an input channel’s current loop anywhere aslong as the current source can provide sufficient voltage toaccommodate all of the voltage drops (each module input is 250ohms)Figure 6.13 shows how to wire the 1756-IF8 module for use in currentmode.Figure 6.13 ControlLogix Analog Input Module Wiring in Current ModeCh0 +Ch0 +Ch0 – Ch0 –CurrentSource ACurrentSource B43369Publication 1756-RM001B-EN-P - October 2003

6-18 ControlLogix I/O ModulesWiring the Thermocouple Input ModuleIn addition to following the General Considerations when using AnyControlLogix Analog Input Module on page 6-13, before wiring themodule, consider the following application guideline:• Wire to Same Input Channel on Both Modules: When wiringthermocouples, wire two in parallel to two modules. Use thesame channel on each module to make sure of consistenttemperature readings.Figure 6.14 shows how to wire the 1756-IT6I module.Figure 6.14 ControlLogix Analog Thermocouple Module WiringCh0 +RTNCh0 +RTNThermocouple AThermocouple B43370Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-19Wiring the RTD Input ModuleIn addition to following the General Considerations when using AnyControlLogix Analog Input Module on page 6-13, before wiring themodule, consider the following application guideline:• RTDs cannot be wired in parallel without severely affecting theiraccuracy. Two sensors must be used.Figure 6.15 shows how to wire the 1756-IR6I module.Figure 6.15 ControlLogix Analog RTD Module WiringCh0 ACh0 ARTD ACh0 BRTNCh0 BRTNRTD B43371Publication 1756-RM001B-EN-P - October 2003

6-20 ControlLogix I/O ModulesUsing Analog OutputModulesThe 1756-OF8 ControlLogix analog output module is certified for useSIL2 applications.General Considerations when using Any ControlLogix AnalogOutput ModuleThere are a number of general application considerations that youmust follow when applying the analog output modules in a SIL2application:• Proof Tests - Periodically (for example, once every severalyears) a System Validation test must be performed. Manually, orautomatically, test outputs to make sure that all outputs areoperational. Channel data should be varied over the fulloperating range to make sure that the corresponding field signallevels vary accordingly. For additional information on ProofTests, see page 1-5 and Figure 9.1 on page 9-5.• Calibrate Outputs Periodically, As Necessary: ControlLogixI/O modules ship from the factory with a highly accurate levelof calibration. However, because each application is different,users are responsible for making sure their ControlLogix I/Omodules are properly calibrated for their specific application.Users can employ tests in application program logic todetermine when a module requires recalibration. For example,to determine whether an output module needs to berecalibrated, a user can determine a tolerance band of accuracyfor a specific application. The user can then measure outputvalues on multiple channels and compare those values toacceptable values within the tolerance band. Based on thedifferences in the comparison, the user could then determinewhether recalibration is necessary.Calibration (and subsequent recalibration) is not a safety issue.However, we recommend that each analog output be calibratedat least every 3 years to verify the accuracy of the input signaland avoid nuisance application shutdowns.Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-21• Choose Floating Point Data Format During ModuleConfiguration: ControlLogix analog output modules perform ahost of on-board alarm processing to validate that the outputsignal is within the proper range for the application. However,these features are only available in Floating Point mode.• Examine the Appropriate Module Fault, Channel Fault andChannel Status Bits to Initiate Fault Routines: Each modulewill communicate the operating status of each channel to thecontroller during normal operation. Application logic mustexamine the appropriate bits to initiate a fault routine for a givenapplication. For more information on faults, see Chapter 7,Faults in the ControlLogix System.• For typical emergency shutdown (ESD) applicationsoutputs must be configured to De-energize: Whenconfiguring any ControlLogix output module, each output mustbe configured to de-energize in the event of a fault and in theevent of the controller going into program mode. For exceptionsto the typical ESD applications, see Chapter 1, SIL Policy.• Wire Output Back to Input and Examination of OutputData Echo signal: Users must wire an analog output to anactuator and then back to an analog input to monitor theoutput’s performance, as shown in Figure 6.17. The applicationlogic must examine the Data Echo value associated with eachoutput point to make sure that the requested output commandfrom the controller was received by the module. The value mustbe compared to the analog input that is monitoring the output tomake sure the value is in an acceptable range for theapplication.In the ladder diagram in Figure 6.16, a user-defined percentageof acceptable deviation (that is, tolerance) is applied to theconfigured range of the analog input and output (that is, range)and the result is stored (that is, delta). This delta value is thenadded to and subtracted from the monitoring analog inputchannel; the results define an acceptable High and Low limit ofdeviation. The analog Output Echo is then compared to theselimits to determine if the output are working properly.The output’s OK bit preconditions a Timer run that is preset toaccommodate an acceptable fault response time and anycommunication filtering, or output, lags in the system. If themonitoring input value and the Output Echo miscompare forlonger than the preset value, a fault is registered with acorresponding alarm.Publication 1756-RM001B-EN-P - October 2003

6-22 ControlLogix I/O ModulesFigure 6.16 Monitoring an Analog Output with an Analog InputOutputs OKTimerMULTRangeTolerance %DeltaADDDeltaMonitoring inputHigh LimitSUBDeltaMonitoring inputLow LimitLIMLow LimitOutput EchoHigh LimitOutputs OKTimer doneOutputs FaultedOutputs FaultedAlarm to OperatorThe control, diagnostics and alarming functions must beperformed in sequence.• When wiring two analog output modules in the sameapplication, make sure:– Both modules use identical configuration.– The same controller owns both modules.Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-23Wiring ControlLogix AnalogOutput ModulesIn general, good design practice dictates that each analog output mustbe wired to a separate input terminal to make sure that the output isfunctioning properly.Wiring the Analog Output Module in Voltage ModeFigure 6.17 shows how to wire the 1756-OF8 module for use involtage mode.Figure 6.17 ControlLogix Analog Output Module Wiring in Voltage ModeAnalog Output ModuleAnalog Input Module(+)(+)Actuator(–)(–)43377Publication 1756-RM001B-EN-P - October 2003

6-24 ControlLogix I/O ModulesWiring the Analog Output Module in Current ModeIn addition to following the General Considerations when using AnyControlLogix Analog Output Module on page 6-20, consider thefollowing application guideline before wiring the 1756-OF8 module incurrent mode:• Placement of Other Devices in Current Loop: you can locateother devices in an output channel’s current loop anywhere aslong as the current source can provide sufficient voltage toaccommodate all of the voltage drops (each module output is250 ohms)Figure 6.18 shows how to wire the 1756-OF8 module for use incurrent mode.Figure 6.18 ControlLogix Analog Output Module Wiring in Current ModeAnalog Output ModuleAnalog Input Module(+)(+)Actuator(–)(–)43376Publication 1756-RM001B-EN-P - October 2003

ControlLogix I/O Modules 6-25Checklist for SIL InputsThe following checklist is required for planning, programming andstart up of SIL inputs. It may be used as a planning guide as well asduring proof testing. If used as a planning guide, the checklist can besaved as a record of the plan.For programming or start-up, an individual checklist can be filled infor every single SIL input channel in a system. This is the only way tomake sure that the requirements were fully and clearly implemented.This checklist can also be used as documentation on the connectionof external wiring to the application program.Input Check List for ControlLogix SystemCompany:Site:Loop definition:SIL input channels in the:No. All Input Module Requirements (apply to both digital and analog input modules) Yes No Comment1 Is Exact Match selected as the electronic keying option for all modules?2 Is the RPI value set to an appropriate value for your application?3 Are all modules owned by the same controller?4 Have you performed proof tests on the system and modules?5 Have you set up the fault routines?6 Are control, diagnostics and alarming functions performed in sequence in application logic?No. Additional Digital Input Module-Only Requirements Yes No Comment1 When two digital input modules are wired in the same application, do the following conditions exist:• Both modules are owned by the same controller.• Sensors are wired to separate input points.• The operational state is ON.• The non-operational state is. OFF.• Configuration parameters (for example, RPI, filter values) are identical.2 For the standard input modules, is the Communication Format set to one of the Input Data choices?3 For the diagnostic input modules, is the Communication Format set to Full Diagnostics-Input Data?4 For the diagnostic input modules, are all diagnostics enabled on the module?5 For the diagnostic input modules, are enabled diagnostic bits monitored by fault routines?6 For the diagnostic input modules, is the connection to remote modules a direct connection?No. Additional Analog Input Module-Only Requirements Yes No Comment1 Is the Communication Format set to Float Data?2 Have you calibrated the modules as often as required by your application?3 Are you using ladder logic to compare the analog input data on two channels to make sure there isconcurrence within an acceptable range and that redundant data is used properly?4 Have you written application logic to examine bits for any condition that may cause a fault andappropriate fault routines to handle the fault condition?5 When wiring the 1756-IF8 in voltage mode, are transmitter grounds tied together?6 When wiring the 1756-IF8 in current mode, are loop devices placed properly?7 When wiring 1756-IT6I modules in parallel, have you wired to the same channel on each module asshown in Figure 6.14 on page 6-18?8 When wiring two 1756-IR6I modules, are two sensors used, as shown in Figure 6.15 on page 6-19?Publication 1756-RM001B-EN-P - October 2003

6-26 ControlLogix I/O ModulesChecklist for SIL OutputsThe following checklist is required for planning, programming andstart up of SIL outputs. It may be used as a planning guide as well asduring proof testing. If used as a planning guide, the checklist can besaved as a record of the plan.For programming or start-up, an individual requirement checklist mustbe filled in for every single SIL output channel in a system. This is theonly way to make sure that the requirements are fully and clearlyimplemented. This checklist can also be used as documentation onthe connection of external wiring to the application program.Output Check List for ControlLogix SystemCompany:Site:Loop definition:SIL output channels in the:No. All Output Module Requirements (apply to both digital and analog output modules) Yes No Comment:1 Have you performed proof tests on the modules?2 Is Exact Match selected as the electronic keying option for all modules?3 Is the RPI value set to an appropriate value for your application?4 Have you set up fault routines, including comparing output data with a corresponding input point?5 If required, have you used external relays in your application to disconnect module power if ashort or other fault is detected on the module or isolated output in series?6 Is the control of the external relay implemented in ladder logic?7 Have you examined the Output Data Echo signal in application logic?8 Are all outputs configured to deenergize in the event of a fault or the controller entering program mode?9 Do two modules of the same type, used in the same application, use identical configurations?10 Does one controller own both modules if two of the same type are used in an application?11 Are control, diagnostics and alarming functions performed in sequence in application logic?No. Digital Output Module-Only Requirements Yes No Comment1 For the standard output modules, is the Communication Format set to Output Data?2 For standard output modules, have you wired the outputs to a corresponding input to validatethat the output is following its commanded state?3 For the diagnostic output modules, are all diagnostics enabled on the module?4 For the diagnostic output modules, are enabled diagnostic bits monitored by fault routines?5 For the diagnostic output modules, is the Communication Format set to FullDiagnostics-Output Data?6 For diagnostic output modules, have you periodically performed a Pulse Test to make surethat the output is capable of change state?7 For diagnostic output modules, is the connection to remote modules a direct connection?No. Analog Output Module-Only Requirements Yes No Comment1 Is the Communication Format set to Float Data?2 Have you calibrated the modules as often as required by your application?3 When wiring the 1756-OF8 in current mode, are loop devices placed properly?4 Have you written application logic to examine bits for any condition that may cause a faultand appropriate fault routines to handle the fault condition?Publication 1756-RM001B-EN-P - October 2003

Chapter 7Faults in the ControlLogix SystemIntroductionThe ControlLogix architecture provides the user many ways ofdetecting and reacting to faults in the system. The first way that userscan handle faults is to make sure they have completed the input andoutput checklists listed on pages 6-25 and 6-26 for their application.In addition to the checklists mentioned above, various device objectscan be interrogated to determine the current operating status.Additionally, modules provide run-time status of their operation andof the process. It is up to users to determine what data is mostappropriate for their application to initiate a shutdown sequence.This chapter explains two example conditions that will generate afault in a SIL2-certified ControlLogix system:• Keyswitch changing out of RUN mode• High alarm condition on an analog input moduleFor more information on the analog status bits available forexamination, see the ControlLogix Analog I/O Modules User Manual,publication 1756-UM009.For information on System Self-Testing andUser-Programmed Responses, see Appendix B.For more information on faults, see Appendix C, AdditionalInformation on Handling Faults in the ControlLogix System.Checking KeyswitchPosition with GSVInstructionThe following rungs generate a fault if the keyswitch on the front ofthe controller is switched from the Run mode:1 Publication 1756-RM001B-EN-P - October 2003

7-2 Faults in the ControlLogix SystemFigure 7.1GSVClass: CONTROLLERDEVICEAttribute: STATUSDestination: KEYSTATEKEYSTATE.13FaultFaultAlarm to OperatorIn this example, the Get System Value (GSV) instruction interrogatesthe STATUS attribute of the CONTROLLERDEVICE object and storesthe result in a word called KEYSTATE, where bits 12 and 13 define thestate of the keyswitch as shown in Table 7.1.Table 7.1Bit 13: Bit 12: Description:0 1 Keyswitch in Run position1 0 Keyswitch in Program position1 1 Keyswitch in Remote positionIf bit 13 is ever ON, then the keyswitch is not in the RUN position.Examining bit 13 of KEYSTATE for an ON state will generate a fault.For more information on the accessing the CONTROLLERDEVICEobject, see the Logix5000 Controllers General Instructions ReferenceManual, publication 1756-RM003.Publication 1756-RM001B-EN-P - October 2003

Faults in the ControlLogix System 7-3Examining an Analog InputModule’s High AlarmControlLogix analog modules perform processing and comparison offield data values right on the module, allowing for easy examinationof status bits to initiate a fault.For example, the 1756-IF8 module can be configured withuser-defined alarm values that, when exceeded, will set a status bit onthe module which is then sent back to the controller. The user maythen examine the state of these bits to initiate a fault as shown inFigure 7.2:Figure 7.2Ch1HAlarmFaultFaultAlarm to OperatorIn the example above, the High Alarm bit for channel 1 (CH1HAlarm)is being examined for an On condition to initiate a fault. Duringoperation, as the analog input module processes analog signals fromthe field sensors, if the value for channel 1 exceeds the user-definedvalue configured for Channel 1’s High Alarm, the (CH1HAlarm) bit isset and sent to the controller and a fault is declared.Publication 1756-RM001B-EN-P - October 2003

7-4 Faults in the ControlLogix SystemNotes:Publication 1756-RM001B-EN-P - October 2003

Chapter 8General Requirements forApplication SoftwareThis chapter discusses the details of the application program.For information about:See page:Software for SIL2-Related Systems 8-1ControlLogix System Operational Modes 8-5SIL2 Programming 8-2General Guidelines for Application Software8-2DevelopmentForcing 8-4Security 8-4Checklist for the Creation of an Application8-6ProgramSoftware for SIL2-RelatedSystemsThe application software for the SIL2-related automation systems isgenerated using the programming tool (RSLogix 5000) according toIEC 61131-3.The application program has to be created by the programming toolRSLogix 5000 and contains the specific equipment functions that areto be carried out by the ControlLogix system. Parameters for theoperating function are also entered into the system usingRSLogix 5000.1 Publication 1756-RM001B-EN-P - October 2003

8-2 General Requirements for Application SoftwareSIL2 ProgrammingSafety Concept of the ControlLogix systemThe safety concept of SIL2 assumes, that:• the programming system (PS) hardware and firmware workscorrectly (that is, programming system errors can be detected).• the user applies the logic correctly, that is, user programmingerrors can be detected.For the initial start-up of a safety-related ControlLogix system, theentire system must be checked by a complete functional test. After amodification of the application program, the modified program orlogic must be checked.For more information on how users should handle changes to theirapplication program, see the Changing Your Application Programsection on page 9-6.General Guidelines forApplication SoftwareDevelopmentThe application software for the intended SIL2 systems is intended tobe developed by the system integrator and/or user. The developermust follow good design practices including the use of:• Functional specifications• Flow charts• Timing diagrams• Sequence charts• Program review• Program validationAll logic should be reviewed and tested. To facilitate reviews andreduce unintended responses, developers should limit the set ofinstructions to basic Boolean/ladder logic (such as examine On/Off,Timers, Counters, etc.) whenever possible. This set should includeinstructions that can be used to accommodate analog variables, suchas:• Limit tests• Comparisons• Math instructionsSee Appendix B, System Self-Testing andUser-Programmed Responses, for details.Publication 1756-RM001B-EN-P - October 2003

General Requirements for Application Software 8-3Users must verify the downloading of the application program and itsproper operation. A typical validation technique is to upload thedownloaded program file and perform a compare of that file againstwhat is stored in the programming terminal. The upload compare canbe accomplished after an interval by saving the first one andcomparing it to the second or subsequent uploads. This approachcould also be performed through different paths (that is, overControlNet and via the serial port).Safety logic and non safety-related logic should be separate.Check the Created Application ProgramTo check the created application program for adherence to thespecific function, you must generate a suitable set of test casescovering the specification. The set of test cases is filed as the testspecification.A suitable test set must also be generated for the numeric evaluationof formulas. Equivalent range tests are acceptable. These are testswithin the defined value ranges, at the limits, or in impermissiblevalue ranges. The test cases must be selected to prove the correctnessof the calculation. The necessary number of test cases depends on theformula used and must comprise critical value pairs.However, active simulation with sources cannot be omitted as this isthe only means of detecting correct wiring of the sensors andactuators to the system. Furthermore, this is the only means of testingthe system configuration. Users should verify the correct programmedfunctions by forcing I/O or by manual manipulation of sensors andactuators.Possibilities of Program IdentificationThe application program is clearly identified by one of the following:• Name• Date• Revision• Any other user identification informationPublication 1756-RM001B-EN-P - October 2003

8-4 General Requirements for Application SoftwareForcingForcing must be disabled after system test and validation.SecurityThe user must define what measures are to be applied for theprotection against manipulation.In the ControlLogix system and in RSLogix 5000, protectionmechanisms are available that prevent unintentional or unauthorizedmodifications to the safety system:• The following tools may be employed for security reasons in aSIL2-certified ControlLogix application:– Logix CPU Security Tool– Source Protection Tool– RSI Security ServerEach of these tools offers different security features, includingpassword protection, at varying levels of granularity throughoutthe application. The description of these tools is too large inscope to list here. Users can contact their local RockwellAutomation representative for more information.• The controller keyswitch should be in the RUN position and thekey removed during normal operating conditions.• Operator options are set up per user login in the ControlLogixsystem.• The link between RSLogix 5000 and the ControlLogix system isnot permitted during normal SIL2 RUN operation.The requirements of the safety and application standards regardingthe protection against manipulations must be observed. Theauthorization of employees and the necessary protection measures arethe responsibility of the individuals starting the system.Publication 1756-RM001B-EN-P - October 2003

General Requirements for Application Software 8-5ControlLogix SystemOperational ModesA three-position keyswitch on the front of the controller governsControlLogix system operational modes. The following modes areavailable:• Run• Program• Remote - This software-enabled mode can be program or run.Figure 8.1 shows a controller with the keyswitch in the Run mode.Figure 8.142525When a SIL2-certified ControlLogix application is operating in the Runmode, the controller keyswitch must be in the RUN position and thekey removed. Outputs are only enabled in this mode.Publication 1756-RM001B-EN-P - October 2003

8-6 General Requirements for Application SoftwareChecklist for the Creation ofan Application ProgramThe following checklist is recommended to maintain safety technicalaspects when programming, before and after loading the new ormodified program.Company:Checklist for Creation of an Application ProgramSafety Manual ControlLogix SystemSite:Project definition:File definition / Archive number:Notes / Checks Yes No CommentBefore a ModificationAre the configuration of the ControlLogix system and theapplication program created on the basis of safety aspects?Are programming guidelines used for the creation of theapplication program?After a Modification - Before LoadingHas a review of the application program with regard to thebinding system specification been carried out by a person notinvolved in the program creation?Has the result of the review been documented and released(date/signature)?Was a backup of the complete program created before loading aprogram in the ControlLogix system?After a Modification - After LoadingWas a sufficient number of tests carried out for the safetyrelevant logical linking (including I/O) and for all mathematicalcalculations?Was all force information reset before safety operation?Has it been verified that the system is operating properly?Have the appropriate security routines and functions beeninstalled?Is the controller keyswitch in Run mode and the key removed?Publication 1756-RM001B-EN-P - October 2003

Chapter 9Technical SIL2 Requirements for theApplication ProgramThis chapter discusses technical safety for the application program.For information about:See page:General Procedure 9-1SIL Task/Program Instructions 9-4Programming Languages 9-4Changing Your Application Program 9-6Forcing 9-8Commissioning Life Cycle 9-5General ProcedureThe general procedure for programming the ControlLogix system SIL2applications is listed below.• Specification of the control function, including:– specification– flow and timing charts– diagrams– sequence charts– program description– program review process• Writing the application program• Checking by independent reviewer• Verification and validationOnce the program is tested, the ControlLogix system can be put intooperation.1 Publication 1756-RM001B-EN-P - October 2003

9-2 Technical SIL2 Requirements for the Application ProgramBasics of ProgrammingThe control program must be available as a specification or aperformance specification. This documentation forms the basis for thecheck of correct transformation into the program. The type ofpresentation of the specification depends on the task to be carriedout. This can be:Logic and InstructionsThe logic and instructions used in programming the application mustbe:• easy to understand• easy to trace• easy to change• easy to testProgram LogicUser must implement simple, easy to understand:• ladder• other IEC 1131-compliant languageor• function blocks with specified characteristics.We use ladder, for example, because, it is easier to visualize and makepartial program changes with this format.Publication 1756-RM001B-EN-P - October 2003

Technical SIL2 Requirements for the Application Program 9-3SpecificationThe specification must include a detailed description that includes (ifapplicable):• Sequence of operations• Flow and timing diagrams• Sequence charts• Program description• Program print out• Verbal descriptions of the steps with step conditions andactuators to be controlled, including:– input definitions– output definitions– I/O wiring diagrams and references– theory of operation• Matrix- or table form of stepped conditions and the actuators tobe controlled, including the sequence and timing diagrams• Definition of marginal conditions, for example, operatingmodes, EMERGENCY STOP etc.The I/O-portion of the specification must contain the analysis of fieldcircuits, that is, the type of sensors and actuators:Sensors (Digital or Analog)• Signal in standard operation (dormant current principle fordigital sensors, sensors OFF means no signal)• Determination of redundancies required for SIL levels• Discrepancy monitoring and visualization, including the user’sdiagnostic logicPublication 1756-RM001B-EN-P - October 2003

9-4 Technical SIL2 Requirements for the Application ProgramActuators• Position and activation in standard operation (normally OFF)• Safe reaction/positioning when switching OFF, power failurerespectively.• Discrepancy monitoring and visualization, including the user’sdiagnostic logicSIL Task/ProgramInstructionsThe user program may contain a single SIL task composed of multipleprograms and routines. This is a timed task with a user-selectable taskpriority and watchdog. The SIL2 task must be the controller’s toppriority and the user-defined program watchdog (software watchdog)must be set to accommodate the SIL2 task and any other tasks. Formore information, see Chapter 1, SIL Policy.Safety logic and non safety-related programs must be separate.Programming LanguagesAll programming languages (for example, ladder logic, functionblock) available in the ControlLogix system will also be available forprogramming the ControlLogix controller for SIL2 applications.Publication 1756-RM001B-EN-P - October 2003

Technical SIL2 Requirements for the Application Program 9-5Commissioning Life CycleFigure 9.1 shows the steps required during application programdevelopment, debugging and commissioning.Figure 9.1Generate FunctionalSpecificationCreate FlowDiagramCreate TimingDiagramsEstablish Sequenceof OperationsDevelop ProjectOnlineDevelop ProjectOfflineReview Programwith IndependentPartyDownload toControllerDevelop Test PlanPerform ValidationTesting on all LogicYesTestsPass?Verificationokay?NoMake more online edits& accept edits or makemore offline edits anddownload to CTRBegin NormalProject OperationNoDetermine what logichas been Changed orAffectedDownload toControllerMake projectchangesPerform ValidationTesting on all Changedor Affected LogicFinish theValidation Test 1Secure PADT1 You must periodically repeat the validation test (also known as proof tests) to make sure module inputs and outputs are functioning properly andas commanded by the application programming. For more information on proof tests for I/O modules, see Chapter 9, ControlLogix I/O Modules.Publication 1756-RM001B-EN-P - October 2003

9-6 Technical SIL2 Requirements for the Application ProgramChanging YourApplication ProgramThe following rules apply to changing your application program inRSLogix 5000:• Program edits are not recommended. However, they arepossible if necessary and should be limited. For example, minorchanges such as changing a timer preset or analog setpointare possible.• Only authorized, specially-trained personnel can make programedits. These personnel should use all supervisory methodsavailable, for example, using the controller keyswitch andsoftware password protections.• When authorized, specially-trained personnel make programedits, they assume the central safety responsibility while thechanges are in progress. These personnel must also maintainsafe application operation.• Prior to making any program edits, an impact analysis must beperformed by following the specification and other lifecyclesteps described in Figure 9.1 as if the edits were an entirelynew program.• Users must sufficiently document all program edits, including:– authorization– impact analysis– execution– test information– revision information• Users cannot make program edits while the program is online ifthe changes prevent the system from executing the safetyfunction or if alternative protection methods are not in place.• Users cannot edit their program from multiple programmingterminals simultaneously.• Changes to the SIS application software, in thiscase--RSLogix 5000, must comply with IEC 61511 standard onprocess safety section 11.7.1 Operator Interface requirements.• Users cannot edit their program when a project is operating inthe RUN state. In other words, if an application is running andthe ControlLogix controller keyswitch is in the RUN position,users cannot make online edits.Publication 1756-RM001B-EN-P - October 2003

Technical SIL2 Requirements for the Application Program 9-7Table 9.1 Methods of Changing Your Application Program in RSLogix 5000• Users can edit the relay ladder logic portion of their programusing one of the following methods described in Table 9.1:Method: Required Steps: ControllerKeyswitchPosition:OfflineOnlineThe user performs the tasks described in the flow chart in Figure 9.1 onpage 9-5.1. Turn the controller key to the REM position.2. Use the Online Edit Toolbar to start, accept, test and assemble youredits. The toolbar is shown below.startpendingrung editacceptpending rungeditsassembleprogrameditstestprogrameditsuntestprogrameditsPROGREMKey Points to this Method:Users must revalidate the entireapplication before returning tonormal operation.The project remains online butoperates in the remote run mode.When edits are completed, usersare only required to validate thechanged portion of the applicationprogram.We recommend that online edits belimited to minor programmodifications such as setpointchanges or ladder logic rungadditions, deletions andmodifications.a. Click the start pending rung edits button . A copy is madeof the rung you want to edit.b. Change your application program as needed. At this point, theoriginal program is still active in the controller. Your programchanges are made in the copied rungs. Changes do not affect theoutputs until you test program edits in step d.c. Click the accept pending rung edits button . Yourprogram changes are verified and downloaded to the controller.The controller now has the changed program and the originalprogram. However, the controller continues to execute theoriginal program. You can see the state of the inputs, andchanges do not affect the outputs.d. Click the test program edits button .e. Click Yes to test the edits. Changes are now executed and affectthe outputs; the original program is no longer executed. However,if you are not satisfied with the result of testing the edits, youcan discard the new program by clicking on the untest programedits button if necessary. If you untest the edits, thecontroller returns to the original program.IMPORTANT: This option tochange theapplication programis available forchanges to relayladder logic only.Users cannot usethis method tochange functionblock programming.For more detailedinformation on howto edit ladder logicwhile online, seethe Logix5000Controllers QuickStart, publication1756-QS001.f. Click the assemble program edits button .g. Click Yes to assemble the edits. The changes are the onlyprogram in the controller, and the original program is discarded.3. Perform a partial proof test of the portion of the application affectedby the program edits.4. Turn the controller key back to the RUN position to return the projectto Run mode. We recommend you upload the new program to yourprogramming terminal to ensure consistency between theapplication in the controller and on the programming terminal.5. Remove the key.Publication 1756-RM001B-EN-P - October 2003

9-8 Technical SIL2 Requirements for the Application Program• If online edits exist in the standard routines only, those edits arenot required to be validated before returning to normaloperation. Users must verify that changes in the standard routinedo not affect SIL routines.IMPORTANTIf any changes are needed to the program in thesafety loop, they must be done so in accordancewith IEC 61511-1, paragraph 11.7.1.5 which states:"The Safety Instrumentation System (SIS) operatorinterface design shall be such as to prevent changesto SIS application software. Where safety informationneeds to be transmitted from the basic processcontrol system (BPCS) to the SIS then systems shouldbe used which can selectively allow writing from theBPCS to specific SIS variables. Equipment orprocedures should be applied to confirm the properselection has been transmitted and received by theSIS and does not compromise the safety function ofthe SIS."Also, for more information on changing the SIL2application program, see Chapter 10.ForcingThe following rules apply to forcing in an RSLogix 5000 project:• Users must remove forces on all SIL2 tags before beginningnormal operation for the project.• Users cannot force SIL2 tags while a project is in the Run mode.Publication 1756-RM001B-EN-P - October 2003

Chapter 10Use and Application of Human toMachine InterfacesNo specific device is part of the certification because the variety ofdevices is so large, ranging from simple thumb-wheel and LEDreadouts to PC/CRT-based human to machine interface (HMI) deviceson a variety of networks. The range and breadth of these devices issimilar to that of sensors and actuators; it would be impractical toimpose device restrictions.Using Precautions andTechniques with HMIHowever, users must exercise the same precautions and techniqueson HMI devices as on simple devices such as sensor and switchinputs. The precautions include, but are not restricted to:• Limited access and security• Specifications, testing and validation• Restrictions on data and access• Limits on data and parametersFor more information on how HMI devices fits into a typical SIL loop,see Figure 1.2 on page 1-4.Sound techniques should be used in either the application softwarewithin the HMI or PLC in safety-related systems and non-safety-relatedsystems.Accessing Safety-Related SystemsNormally, when accessing the safety-related system, the HMI shouldbe restricted to read data and information such as diagnostics. Theuser should use techniques to limit access to only those sections ofmemory that are appropriate. For more information, see Figure 1.2 onpage 1-4.If parameters in safety-related system require a change from an HMI,users should follow the guidelines indicated in the next section.1 Publication 1756-RM001B-EN-P - October 2003

10-2 Use and Application of Human to Machine InterfacesChanging Parameters in Safety-Related SystemsA parameter change in a safety-related loop via an external (that is,outside the safety loop) device (for example, an HMI) is only allowedwith the following restrictions:• Only authorized, specially-trained personnel can change theparameters in safety-related systems via HMIs.• The user who makes changes in a safety-related system via anHMI is responsible for the effect of those changes on thesafety loop.• Users must clearly identify the variable that are to be changed asunder the control of the ControlLogix controller inside thesafety loop.• Users must use a clear, comprehensive and explicit operatorprocedure to make safety-related changes via an HMI.• Changes can only be accepted in a safety-related system if thefollowing sequence of events occurs:a. Changes are sent from the HMI to the ControlLogix controllerin the safety loop.b. The ControlLogix controller in the safety loop sends thechanges back to the HMI–before accepting the changes oracting on them.c. The user verifies that the changes are correct.In every case, the operator must confirm the validity of thechange before they are accepted and applied in the safety loop.• The software used in the HMI and the ControlLogix controller(in this case, RSLogix 5000) should be designed to verify thatchanges to the safety system are within acceptable limits and donot otherwise compromise the safety system.• The user should test all changes as part of the safety validationprocedure.Publication 1756-RM001B-EN-P - October 2003

Use and Application of Human to Machine Interfaces 10-3• Users must sufficiently document all safety-related changesmade via HMI, including:– authorization– impact analysis– execution– test information– revision information• Changes to the safety-related system, must comply with IEC61511 standard on process safety section 11.7.1 OperatorInterface requirements.Changing Parameters in Non-Safety-Related SystemsWhen the HMI device is used to change parameters in anon-safety-related system, remember the following techniques:• When the HMI is used to input parameters such as setpoints fora PID loop or drive speeds, the application program shouldinclude sound techniques used for other types of changevalidation, including:– Display the data to be changed– Acceptable ranges and limits used in the program for datachecks (in other words, checks to make sure entered data iswithin an acceptable range)– Display the new value along with the existing value– Prompt the operator to acknowledge and accept the changedvalue before allowing the change to take effect• The developer must follow the same sound developmenttechniques and procedures used for other application softwaredevelopment, including the verification and testing of theoperator interface and its access to other parts of the program.The PLC application software should set up a table that isaccessible by the HMI and limits access to required data pointsonly.• Similar to the PLC program, the HMI software needs to besecured and maintained for SIL2 compliance after the system hasbeen validated and tested.Publication 1756-RM001B-EN-P - October 2003

10-4 Use and Application of Human to Machine InterfacesNotes:Publication 1756-RM001B-EN-P - October 2003

Appendix AResponse Times in ControlLogixThe following calculation methods provide the user with theworst-case reaction times for a given change in input or faultcondition and the corresponding output action.Digital ModulesLocal Chassis ConfigurationFigure A.1 shows an example system where the following occurs:• input data changes on the digital input module• the data is transmitted to the controller• the controller runs its program scan and reacts to the datachange, including sending new data to the output module• the output module behavior changes based on the new datareceived from the controllerFigure A.1Digital InputModuleControllerDigital OutputModuleUse the following formula to determine worst-case reaction time:Worst-Case Reaction Time = Input Module Filter Setting (1) + Input Module Hardware Delay (2)+ Input Module RPI (1) + Controller Program Scan (3)+ Output Module Hardware Delay (2)(1)This setting is user-defined. For more information, see the ControlLogix Digital I/O Modules user manual,publication 1756-UM058.(2) Hardware delay is module-dependent. Specific hardware delay times are listed in the installation instructions for eachcatalog number. For a complete list of installation instructions, see Table 1.1 on page 1-6.(3)This figure is calculated by adding instruction execution times. For more information on instruction execution times inRSLogix 5000, see the Logix5000 Controllers Execution Time and Memory Use Reference, publication 1756-RM087.1 Publication 1756-RM001B-EN-P - October 2003

A-2 Response Times in ControlLogixEXAMPLEFor example, a system may reflect the set-up used inFigure A.1 with an 1756-IB16D and 1756-OB16D andfollowing settings:• Input Module Filter Setting = 1ms• Input Module Hardware Delay = 1ms• Input RPI = 2ms• Program Scan = 20ms• Output Module Hardware Delay = 1msIn this example, the worst-case reaction time = 25msRemote Chassis ConfigurationFigure A.2 shows an example system where the following occurs:• input data changes on the digital input module• the data is transmitted to the controller via the 1756-CNBmodules• the controller runs its program scan and reacts to the datachange, including sending new data to the output module viathe 1756-CNB modules• the output module behavior changes based on the new datareceived from the controllerFigure A.2ControllerControlNetBridge ModuleControlNetBridge ModuleDigital InputModuleDigital OutputModulePublication 1756-RM001B-EN-P - October 2003

Response Times in ControlLogix A-3Use the following formula to determine worst-case reaction time:Worst-Case Reaction Time =Input Module Filter Setting (1) + Input Module Hardware Delay (2)+ Input Module RPI (1) + Remote 1756-CNB RPI + Controller Program Scan (3)+ Remote 1756-CNB RPI + Output Module Hardware Delay (2)(1)This setting is user-defined. For more information, see the ControlLogix Digital I/O Modules user manual, publication 1756-UM058.(2) Hardware delay is module-dependent. Specific hardware delay times are listed in the installation instructions for each catalog number.For a complete list of installation instructions, see Table 1.1 on page 1-6.(3)This figure is calculated by adding instruction execution times. For more information on instruction execution times in RSLogix 5000, seethe Logix5000 Controllers Execution Time and Memory Use Reference, publication 1756-RM087.Analog ModulesLocal Chassis ConfigurationFigure A.3 shows an example system where the following occurs:• input data changes on the analog input module• the data is transmitted to the controller• the controller runs its program scan and reacts to the datachange, including sending new data to the output module• the output module behavior changes based on the new datareceived from the controllerFigure A.3Analog InputModuleControllerAnalog OutputModuleUse the following formula to determine worst-case reaction time:Worst-Case Reaction Time =Input Module Filter Setting (1) + Input Module Real Time Sample (RTS) rate (1)+ Controller Program Scan (2) +Output Module RPI (1)+ Output Module Hardware Delay (3)(1)(2)(3)This setting is user-defined. For more information, see the ControlLogix Digital I/O Modules user manual, publication 1756-UM058.This figure is calculated by adding instruction execution times. For more information on instruction execution times in RSLogix 5000, see theLogix5000 Controllers Execution Time and Memory Use Reference, publication 1756-RM087.Hardware delay is module-dependent. Specific hardware delay times are listed in the installation instructions for each catalog number. Fora complete list of installation instructions, see Table 1.1 on page 1-6.Publication 1756-RM001B-EN-P - October 2003

A-4 Response Times in ControlLogixRemote Chassis ConfigurationFigure A.2 shows an example system where the following occurs:• input data changes on the analog input module• the data is transmitted to the controller via the 1756-CNBmodules• the controller runs its program scan and reacts to the datachange, including sending new data to the output module viathe 1756-CNB modules• the output module behavior changes based on the new datareceived from the controllerFigure A.4ControllerControlNetBridge ModuleControlNetBridge ModuleAnalog InputModuleAnalog OutputModuleUse the following formula to determine worst-case reaction time:Worst-Case Reaction Time =Input Module Filter Setting (1) + Input Module Real Time Sample (RTS) rate (1)+ Remote 1756-CNB RPI (1) + Controller Program Scan (2) + Output Module RPI (1)+ Remote 1756-CNB RPI (1) + Output Module Hardware Delay (3)(1)This setting is user-defined. For more information, see the ControlLogix Digital I/O Modules user manual, publication 1756-UM058.(2)This figure is calculated by adding instruction execution times. For more information on instruction execution times in RSLogix 5000, see theLogix5000 Controllers Execution Time and Memory Use Reference, publication 1756-RM087.(3) Hardware delay is module-dependent. Specific hardware delay times are listed in the installation instructions for each catalog number. For acomplete list of installation instructions, see Table 1.1 on page 1-6.Publication 1756-RM001B-EN-P - October 2003

Appendix BSystem Self-Testing andUser-Programmed ResponsesThis chapter explains self-testing in a ControlLogix system and pointsto more information about user-programmed responses.Validation TestsValidation tests are performed at every proof test interval.• Manually Cycle Inputs to ensure that all inputs are operationaland not stuck in the ON state• Manually Pulse Test outputs which do not support runtime PulseTesting. The relays in the Redundant Power Supplies mustbe tested to ensure they are not stuck in the Closed state.Users can automatically perform proof tests by switching groundopen on input modules and checking to make sure all inputpoints go to zero (turn OFF.).All system components which do not have runtime diagnostics mustbe tested as part of the System Initialization Tests.System Self TestsThe SIL2-certified ControlLogix system is designed to automaticallyshut down in the event of a failure or fault. The following informationprovides details on how to program and configure routines to monitordiagnostic and system status.1 Publication 1756-RM001B-EN-P - October 2003

B-2 System Self-Testing and User-Programmed ResponsesReaction to FaultsFor more information on how to configure a ControlLogix system toidentify and handle faults, including such tasks as:• Developing a Fault Routine• Creating a User-Defined Major Fault• Monitoring Minor Faults• Developing a Power-Up Routinesee the Logix5000 Controllers Common Procedures ProgrammingManual, publication 1756-PM001.Publication 1756-RM001B-EN-P - October 2003

Appendix CAdditional Information on Handling Faults inthe ControlLogix SystemThis appendix describes the ways that faults are reported to thecontroller.IntroductionThe ControlLogix architecture provides the user many ways ofdetecting and reacting to faults in the system. Various device objectscan be interrogated to determine the current operating status.Additionally, modules provide run-time status of their operation andof the process.• For information on how to use specific instructions to get andset controller system data stored in device objects, see theLogix5000 Controllers General Instructions Reference Manual,publication 1756-RM003.• For information on controller fault codes, including major andminor codes, see the Logix5000 Controllers Common ProceduresProgramming Manual, publication 1756-PM001.• For information on accessing modules’ run-time operational andprocess status, see the ControlLogix Analog I/O Modules UserManual, publication 1756-UM009, and the ControlLogix DigitalI/O Modules User Manual, publication 1756-UM058.1 Publication 1756-RM001B-EN-P - October 2003

C-2 Additional Information on Handling Faults in the ControlLogix SystemNotes:Publication 1756-RM001B-EN-P - October 2003

Appendix DSpurious Failure EstimatesTable D.1 lists the Spurious failure estimates for the ControlLogixproducts included in this manual. These estimates are based on fieldreturns.Table D.1Catalog Number: Description: MTBF (Spurious): (1) λ (Spurious): (2)1756-Ax ControlLogix Chassis 1,689,662(Average) 5.92E-071756-CNB ControlNet Bridge 2,335,907 4.28E-071756-CNBR Redundant ControlNet Bridge 3,360,686 2.98E-071756-ENBT EtherNet Bridge 167,440 4.28E-071756-IA16I Isolated AC Input 11,623,040 8.60E-081756-IA8D AC Diagnostic Input 4,018,560 2.49E-071756-IB16D DC Diagnostic Input 12,024,480 8.32E-081756-IB16I DC Isolated Input 20,454,720 4.89E-081756-IF8 Analog Input 3,788,373 2.64E-071756-IR6I RTD Input 1,294,453 7.73E-071756-IT6I Thermocouple Input 805,376 1.24E-061756-L55M16 L55 Controller w 7.5Mb Memory 447,497 2.23E-061756-OA16I AC Isolated Input 4,440,800 2.25E-071756-OA8D AC Diagnostic Input 3,956,160 2.53E-071756-OB16D DC Diagnostic Output 7,317,440 1.37E-071756-OB16I DC Isolated Output 15,329,600 6.52E-081756-OB8EI DC Fused Output 1,356,160 7.37E-071756-OF8 Analog Output 2,542,138 3.93E-071756-OX8I Contact Output 7,096,960 1.41E-071756-PA75 AC Power Supply 2,020,247 4.95E-071756-PA75R AC Redundant PS 511,680 1.95E-061756-PB75 DC Power Supply 2,275,520 4.39E-071756-PB75R DC Redundant PS NA1756-PSCA Power Sup Chassis Adapter 3,132,480 3.19E-07(1) MTTF (Spurious) = (Installed base one year ago X 4160) / Number of "No Problem Found" failures in the past 12 months (in hours)NOTE: If no "No Problem Found" failures are recorded, one (1) is assumed.(2)λ (Spurious) = 1 / MTTF (Spurious)NA - Sufficient field data is not available1 Publication 1756-RM001B-EN-P - October 2003

D-2 Spurious Failure EstimatesNotes:Publication 1756-RM001B-EN-P - October 2003

Appendix ESample Probability of Failure onDemand (PFD) CalculationsProof Test Interval = 2 YearsTable E.1 shows PFD calculations for a proof test interval of 2 years.Table E.1 ControlLogix Product Probability of Failure on Demand Calculations – Proof Test Interval of 2 YearsCatalogNumberDescription1756-Axx ControlLogix Chassis 40,143,919 (2)Mean Time λ (5) Calculated PFD:Between Failure(MTBF) (1) 1oo1 architecture 1oo2 architecture(average (3) )2.49E-081.10E-051756-CNB ControlNet Bridge 3,596,087 (2) 2.78E-07 1.23E-041756-CNBR Redundant ControlNet Bridge 3,385,813 (2) 2.95E-07 1.31E-041756-IA16I AC Isolated Input 4,144,192 2.41E-07 8.70E-061756-IA8D AC Diagnostic Input 3,856,320 2.59E-07 9.37E-061756-IB16D DC Diagnostic Input 7,386,774 1.35E-07 4.83E-061756-IB16I DC Isolated Input 3,562,624 2.81E-07 1.02E-051756-IF8 Analog Input 1,690,694 5.91E-07 2.22E-051756-IR6I RTD Input 3,456,960 2.89E-07 1.05E-051756-IT6I Thermocouple Input 4,784,000 2.09E-07 7.51E-061756-L55M16 ControlLogix 5555 Controller 2,855,348 (2) 3.50E-07 1.55E-041756-OA16I AC Isolated Output 1,994,720 5.01E-07 1.86E-051756-OA8D AC Diagnostic Output 3,839,680 2.60E-07 1.15E-041756-OB16D DC Diagnostic Output 4,520,534 2.21E-07 9.80E-051756-OB16I DC Isolated Output 1,703,520 5.87E-07 2.20E-051756-OB8EI DC Fused Output 1,239,680 8.07E-07 3.09E-051756-OF8 Analog Output 2,054,694 4.87E-07 1.80E-051756-OX8I Contact Output 6,639,360 1.51E-07 5.38E-061 Publication 1756-RM001B-EN-P - October 2003

E-2 Sample Probability of Failure on Demand (PFD) CalculationsTable E.1 ControlLogix Product Probability of Failure on Demand Calculations – Proof Test Interval of 2 YearsCatalogNumberDescriptionMean Time λ (5) Calculated PFD:Between Failure(MTBF) (1) 1oo1 architecture 1oo2 architecture1756-PA75 AC Power Supply 7,301,935 (2) 1.37E-07 6.07E-051756-PA75R AC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 1.01E-071756-PB75 DC Power Supply 7,100,760 (2) 1.41E-07 6.24E-051756-PB75R DC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 1.01E-071756-PSCAPower Sup Chassis AdapterModule45,146,727 (2) 2.21E-08 9.81E-06(1) MTBF measured in hours.(2)Calculated using field based values for components(3)Average = The arithmetic average of the MTBFs of all five Chassis (1756-A4, A7, A10, A13, and A17)(4)Assumes that both power supplies fail simultaneously(5)λ = Failure Rate = 1/MTBFTable E.2 shows an example of a PFD calculation for a safety loopinvolving two DC input modules used in a 1oo2 configuration and aDC output module using a proof test interval of 2 years.Table E.2Catalog Number: Description: MTBF: Calculated PFD:1756-Axx ControlLogix Chassis 40,143,900 1.10E-05(average)1756-L55M16 ControlLogix 5555 2,855,348 1.55E-04Controller1756-OB16D DC Output 4,520,534 9.80E-051756-IB16D DC Diagnostic Input 7,386,774 4.83E-06Total PFD calculation for a safety loop consisting of these products: 2.69E-04Publication 1756-RM001B-EN-P - October 2003

Sample Probability of Failure on Demand (PFD) Calculations E-3Proof Test Interval = 4 YearsTable E.3 shows PFD calculations for a proof test interval of 4 years.Table E.3 ControlLogix Product Probability of Failure on Demand Calculations – Proof Test Interval of 2 YearsCatalogNumberDescription1756-Axx ControlLogix Chassis 40,143,919 (2)Mean Time λ (5) Calculated PFD:Between Failure(MTBF) (1) 1oo1 architecture 1oo2 architecture(average (3) )2.49E-082.19E-051756-CNB ControlNet Bridge 3,596,087 (2) 2.78E-07 2.45E-041756-CNBR Redundant ControlNet Bridge 3,385,813 (2) 2.95E-07 2.60E-041756-IA16I AC Isolated Input 4,144,192 2.41E-07 1.79E-051756-IA8D AC Diagnostic Input 3,856,320 2.59E-07 1.93E-051756-IB16D DC Diagnostic Input 7,386,774 1.35E-07 9.79E-061756-IB16I DC Isolated Input 3,562,624 2.81E-07 2.09E-051756-IF8 Analog Input 1,690,694 5.91E-07 4.71E-051756-IR6I RTD Input 3,456,960 2.89E-07 2.16E-051756-IT6I Thermocouple Input 4,784,000 2.09E-07 1.54E-051756-L55M16 ControlLogix 5555 Controller 2,855,348 (2) 3.50E-07 3.09E-041756-OA16I AC Isolated Output 1,994,720 5.01E-07 3.92E-051756-OA8D AC Diagnostic Output 3,839,680 2.60E-07 2.29E-041756-OB16D DC Diagnostic Output 4,520,534 2.21E-07 1.95E-041756-OB16I DC Isolated Output 1,703,520 5.87E-07 4.67E-051756-OB8EI DC Fused Output 1,239,680 8.07E-07 6.70E-051756-OF8 Analog Output 2,054,694 4.87E-07 3.79E-051756-OX8I Contact Output 6,639,360 1.51E-07 1.09E-051756-PA75 AC Power Supply 7,301,935 (2) 1.37E-07 1.21E-041756-PA75R AC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 2.01E-071756-PB75 DC Power Supply 7,100,760 (2) 1.41E-07 1.24E-041756-PB75R DC Redundant Power Supply 4,380,000,000 (2), (4) 2.28E-10 2.01E-071756-PSCAPower Sup Chassis AdapterModule45,146,727 (2) 2.21E-08 1.95E-05(1) MTBF measured in hours.(2) Calculated using field based values for components(3)(4)(5)Average = The arithmetic average of the MTBFs of all five Chassis (1756-A4, A7, A10, A13, and A17)Assumes that both power supplies fail simultaneouslyλ = Failure Rate = 1/MTBFPublication 1756-RM001B-EN-P - October 2003

E-4 Sample Probability of Failure on Demand (PFD) CalculationsTable E.4 shows an example of a PFD calculation for a safety loopinvolving two DC input modules used in a 1oo2 configuration and aDC output module using a proof test interval of 4 years.Table E.4Catalog Number: Description: MTBF: Calculated PFD:1756-Axx ControlLogix Chassis 40,143,900 2.19E-05(average)1756-L55M16 ControlLogix 5555 2,855,348 3.09E-04Controller1756-OB16D DC Output 4,520,534 1.95E-041756-IB16D DC Diagnostic Input 7,386,774 9.79E-06Total PFD calculation for a safety loop consisting of these products: 5.36E-04Publication 1756-RM001B-EN-P - October 2003

IndexAAgency certifications 1-15Analog input modules 6-13–6-19Analog output modules 6-20–6-24Application programProgramming languages 9-4SIL task/program instructions 9-4Technical SIL2 requirements 9-1–9-8ArchitectureOverview of ControlLogix architecture2-2CCalibration 6-13, 6-20Chassis 3-2Commissioning life cycle 9-5CommunicationControlNet 2-6, 5-2Ethernet 5-2Field side output verification 2-4Output data echo 2-4, 6-8Producer/consumer model 2-2Communications modules 5-1–5-4ControlNet module 5-2Documentation 5-4Ethernet module 5-2Usage recommendations 5-3Control and information protocolDefinition Preface-2Controller 4-1–4-2Documentation 4-2Usage recommendations 4-2ControlLogix architecture 2-2ControlNet module 5-2DDiagnostic coverageDefinition Preface-2DocumenationController 4-2DocumentationCommunications modules 5-4Hardware 3-5EEthernet module 5-2European norm.Definition Preface-2FFault handling 2-3, 7-1–7-3, B-1, C-1Fault reporting 2-3, 6-4, 7-1–7-3, B-1,C-1Analog input modules 6-14Analog output modules 6-21Digital input modules 6-6Digital output modules 6-8, 6-12Field side output verification 2-4Forcing via software 8-4GGet system value (GSV)Defintion Preface-2HHardware 3-1–3-5Chassis 3-2Documentation 3-5Power supplies 3-2–3-3Usage recommendations 3-4Human to machine interfacesUse and application 10-1–10-3II/O modules 6-1–6-26Analog input modules 6-13–6-19Analog output modules 6-20–6-24Calibration 6-13, 6-20Digital input modules 6-4–6-6Digital output modules 6-7–6-12Fault reporting 6-4, 6-6, 6-8, 6-12,6-14, 6-21List of SIL2-certified catalog numbers6-3Proof tests 6-5, 6-8, 6-13, 6-20Response times A-1–A-4Wiring analog input modules 6-16–6-19Wiring analog output modules 6-23–6-24Wiring digital input modules 6-6Wiring digital output modules 6-10–6-12InterfaceHMI use and application 10-1–10-3Publication 1756-RM001B-EN-P - October 2003

2 IndexMMean time between failures (MTBF)Definition Preface-2Mean time to restorationDefinition Preface-2OOperational modes 8-5Output data echo 2-4, 6-8PPower supplies 3-2–3-3Non-redundant 3-3Redundant 3-3Probability of failure on demand (PFD)1-8–1-13Calculation equation 1-9Calculations for each catalog number1-10, E-1, E-3Definition Preface-2Probability of failure per hour (PFH) 1-8–1-13Calculation equation 1-10Calculations for each catalog number1-12Definition Preface-2Producer/consumer communicationmodel 2-2Programming languages 9-4Proof tests 1-5, 6-5, 6-8, 6-13, 6-20Pulse test 2-5RResponse times A-1–A-4RSLogix 5000 Preface-2, 2-6Changing your application program 9-6Commissioning life cycle 9-5Forcing 8-4General requirements 8-1–8-6Programming languages 9-4Security 8-4SIL task/program instructions 9-4SIL2 programming 8-2SSafety certifications and compliancesFor ControlLogix catalog numbers 1-7Security via software 8-4SIL complianceDistribution and weight 1-14SIL loop example 1-4SIL policy 1-1–1-16SIL2 requirementsFor the application program 9-1–9-8SIL2-certified componentsComplete list of ControlLogix catalognumbers 1-6SoftwareChanging your application program 9-6Commissioning life cycle 9-5Forcing 8-4General requirements 8-1–8-6Programming languages 9-4RSLogix 5000 Preface-2, 2-6Security 8-4SIL task/program instructions 9-4SIL2 programming 8-2Software watchdog 1-16Spurious failure estimates D-1System hardware 3-1–3-5Chassis 3-2Documentation 3-5Power supplies 3-2–3-3Usage recommendations 3-4TTerminologyUsed throughout manual Preface-2WWatchdog 1-16Wiring I/O modulesAnalog input modules 6-16–6-19Analog output modules 6-23–6-24Digital input modules 6-6Digital output modules 6-10–6-12Publication 1756-RM001B-EN-P - October 2003

Rockwell AutomationSupportRockwell Automation tests all of our products to ensure that they arefully operational when shipped from the manufacturing facility.If you are experiencing installation or startup problems, please reviewthe troubleshooting information contained in this publication first. Ifyou need technical assistance to get your module up and running,please contact Customer Support (see the table below); our trainedtechnical specialists are available to help.If the product is not functioning and needs to be returned, contactyour distributor. You must provide a Customer Support case numberto your distributor in order to complete the return process.PhoneUnitedStates/CanadaOutside UnitedStates/Canada1.440.646.5800You can access the phone number for your country viathe Internet:1. Go to http://support.rockwellautomation.com/2. Under Contacting Customer Support and OtherCountries, click on Click hereInternet Worldwide Go to http://support.rockwellautomation.com/Your Questions or Comments on this ManualIf you find a problem with this manual, please notify us of it on theenclosed How Are We Doing form.Publication 1756-RM001B-EN-P - October 2003 2 PN 957782-51Supersedes Publication 1756-RM001A-EN-P - September 2002Copyright © 2003 Rockwell Automation, Inc. All rights reserved. Printed in the U.S.A.