1756-RM001B-EN-P, Using ControlLogix in SIL2 ... - Tuv-fs.com
1756-RM001B-EN-P, Using ControlLogix in SIL2 ... - Tuv-fs.com 1756-RM001B-EN-P, Using ControlLogix in SIL2 ... - Tuv-fs.com
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
- Page 1: Using ControlLogixin SIL2 Applicati
- Page 4 and 5: Summary of Changes 2Notes:Publicati
- Page 6 and 7: Preface 2Table Preface.1Section: Ti
- Page 8 and 9: Table of Contents 2ControlLogix Com
- Page 10 and 11: Table of Contents 4Additional Infor
- Page 12 and 13: 1-2 SIL PolicyThe TUV Rheinland has
- Page 14 and 15: 1-4 SIL PolicySIL2 CertificationFig
- Page 16 and 17: 1-6 SIL PolicySIL2-Certified Contro
- Page 18 and 19: 1-8 SIL PolicyHardware Designs andF
- Page 20 and 21: 1-10 SIL PolicyCatalogNumberDescrip
- Page 22 and 23: 1-12 SIL PolicyCatalogNumberDescrip
- Page 24 and 25: 1-14 SIL PolicySIL ComplianceDistri
- Page 26 and 27: 1-16 SIL PolicyProgram Watchdog Tim
- Page 30 and 31: 2-4 The ControlLogix SystemData Ech
- Page 32 and 33: 2-6 The ControlLogix SystemSoftware
- Page 34 and 35: 2-8 The ControlLogix SystemNotes:Pu
- Page 36 and 37: 3-2 ControlLogix System HardwareCon
- Page 38 and 39: 3-4 ControlLogix System HardwareRec
- Page 40 and 41: 3-6 ControlLogix System HardwareNot
- Page 42 and 43: 4-2 ControlLogix ControllerRecommen
- Page 44 and 45: 5-2 ControlLogix Communications Mod
- Page 46 and 47: 5-4 ControlLogix Communications Mod
- Page 48 and 49: 6-2 ControlLogix I/O ModulesFigure
- Page 50 and 51: 6-4 ControlLogix I/O ModulesModule
- Page 52 and 53: 6-6 ControlLogix I/O ModulesWiring
- Page 54 and 55: 6-8 ControlLogix I/O ModulesGeneral
- Page 56 and 57: 6-10 ControlLogix I/O ModulesWiring
- Page 58 and 59: 6-12 ControlLogix I/O ModulesApplic
- Page 60 and 61: 6-14 ControlLogix I/O Modules• Ch
- Page 62 and 63: 6-16 ControlLogix I/O ModulesWiring
- Page 64 and 65: 6-18 ControlLogix I/O ModulesWiring
- Page 66 and 67: 6-20 ControlLogix I/O ModulesUsing
- Page 68 and 69: 6-22 ControlLogix I/O ModulesFigure
- Page 70 and 71: 6-24 ControlLogix I/O ModulesWiring
- Page 72 and 73: 6-26 ControlLogix I/O ModulesCheckl
- Page 74 and 75: 7-2 Faults in the ControlLogix Syst
- Page 76 and 77: 7-4 Faults in the ControlLogix Syst
2-2 The <strong>ControlLogix</strong> SystemIf an anomaly (other than automatic shutdown) is detected, the systemcan be programmed to <strong>in</strong>itiate user-def<strong>in</strong>ed fault handl<strong>in</strong>g rout<strong>in</strong>es.Output modules can turn OFF selected outputs <strong>in</strong> the event of afailure. New diagnostic I/O modules self-test to make sure that fieldwir<strong>in</strong>g is function<strong>in</strong>g. Output modules use pulse test<strong>in</strong>g to make sureoutput switch<strong>in</strong>g devices are not shorted. <strong>Us<strong>in</strong>g</strong> these <strong>in</strong>ternalfeatures, as well as application software when needed, today’s<strong>ControlLogix</strong> customers are able to achieve highly reliable controlsystems.Overview of the<strong>ControlLogix</strong> ArchitectureRockwell Automation’s latest generation of programmable controllersis the <strong>ControlLogix</strong> system. Inherent <strong>in</strong> its design and implementationare several features that surpass anyth<strong>in</strong>g offered <strong>in</strong> previous productarchitectures. The <strong>in</strong>clusion of these features represent improvementsdriven by customer demand for uptime and reliability as well asRockwell’s long-developed design experience <strong>in</strong> produc<strong>in</strong>g thesetypes of products.One of the most significant changes <strong>in</strong> the architecture is theimplementation of the Producer/Consumer (P/C) <strong>com</strong>municationmodel between controller and I/O. The P/C <strong>com</strong>munication modelreplaces traditional ‘poll<strong>in</strong>g’ of I/O modules and, consequently, haschanged the overall behavior of these <strong>com</strong>ponents vis-a-vis theircounterparts <strong>in</strong> previous architectures. Input modules “produce” data,controller and output modules both “produce” and “consume” data.These changes were embraced because of the enhanced data <strong>in</strong>tegrityand fault report<strong>in</strong>g capabilities they provide. I/O modules nowexchange much more than simply the ON/OFF state of the devicesthey are connected to. Module identification <strong>in</strong>formation,<strong>com</strong>munication status, fault codes and, through the use o<strong>fs</strong>pecially-designed modules, field-side diagnostics can now all beretrieved from the I/O system as part of the standard feature set of theProducer/Consumer <strong>com</strong>munication model. (See Figure 2.1).Figure 2.1Producer/Consumer Communication ModelLogix ControllerInput ModulesOutput ModulesCommonly Shared Data43374Publication <strong>1756</strong>-<strong>RM001B</strong>-<strong>EN</strong>-P - October 2003
Change language