The Programmable Logic · This document provides recommendations to guide reviewers in the...

NUREG/CR-6090UCRL-ID-112900

The Programmable LogicController and ItsApplication inNuclear Reactor Systems

Prepared byJ. Palomar, R. Wyman

Lawrence Livermore National Laboratory

Prepared forU.S. Nuclear Regulatory Commission

AVAILABILITY NOTICE

Availability of Reference Materials Cited in NRC Publications

Most documents cited In NRC publications wi, be available from one of the following sources:

1. The NRC Public Document Room. 2120 L Street, NW, Lower Level. WashIngton, DC 20555-0001

2. The Superintendent of Documents, U.S. Government Printing Office. Mail Stop SSOP, Washington.

DC 20402-9328

3. The National Technical Information Service, Springfield, VA 22161

Although the listing that follows represents the majority of documents cited In NRC publications. It Is notIntended to be exhaustive.

Referenced documents available for Inspection and copying for a fee from the NRC Public Document RoomInclude NRC correspondence and Internal NRC memoranda; NRC Office of Inspection and Enforcementbulletins, circulars, Information notices. Inspection and Investigation notices; Licensee Event Reports; ven-dor reports and correspondence; Commission papers; and applicant and licensee documents and corre-spondence.

The following documents In the NUREG series are available for purchase from the GPO Sales Program:formal NRC staff and contractor reports, NRC-sponsored conference proceedings, and NRC booklets andbrochures. Also available are Regulatory Guides, NRC regulations In the Code of Federal Regulations, andNuclear Regulatory Commission Issuances.

Documents available from the National Technical Information Service Include NUREG series reports andtechnical reports prepared by other federal agencies and reports prepared by the Atomic Energy Commis-sion, forerunner agency to the Nuclear Regulatory Commission.

Documents available from public and special technical libraries Include all open literature items, such asbooks, journal and periodical articles, and transactions. Federal Register notices, federal and state legisla-tion, and congressional reports can usually be obtained from these libraries.

Documents such as theses, dissertations, foreign reports and translations, and non-NRC conference pro-ceedings are available for purchase from the organization sponsoring the publication cited.

Single copies of NRC draft reports are available free, to the extent of supply, upon written request to theOffice of Information Resources Management. Distribution Section. U.S. Nuclear Regulatory Commission,Washington. DC 20555-0001.

Copies of industry codes and standards used In a substantive manner In the NRC regulatory process aremaintained at the NRC Library, 7920 Norfolk Avenue. Bethesda, Maryland, and are available there for refer-ence use by the public. Codes and standards are usually copyrighted and may be purchased from theoriginating organization or. If they are American National Standards, from the American National StandardsInstitute, 1430 Broadway, New York, NY 10018.

DISCLAIMER NOTICE

This report was prepared as an account of work sponsored by an agency of the United States Government.Neither the United States Government nor any agency thereof, or any of their employees, makes any warranty,expresed or implied, or assumes any legal liability of responsibility for any third party's use, or the results ofsuch use, of any information, apparatus, product or process disclosed in this report, or represents that its useby such third party would not infringe privately owned rights.

NUREG/CR-6090UCRL-ID-112900

The- Programmable LogicController and ItsApplication inNuclear Reactor Systems

Manuscript Completed: August 1993Date Published: September 1993

Prepared byJ. Palomar, R. Wyman

Lawrence Livermore National LaboratoryP.O. Box 808Livermore, CA 94550

Prepared forDivision of Reactor Controls and Human FactorsOffice of Nuclear Reactor RegulationU.S. Nuclear Regulatory CommissionWashington, DC 20555-0001NRC FIN L1867

Abstract

This document provides recommendations to guide reviewers in the application of Programmable Logic Controllers(PLCs) to the control, monitoring and protection of nuclear reactors. The first topics addressed are system-leveldesign issues, specifically including safety. The document then discusses concerns about the PLC manufacturingorganization and the protection system engineering organization. Supplementing this document are two appendices.Appendix A summarizes PLC characteristics. Specifically addressed are those characteristics that make the PLCmore suitable for emergency shutdown systems than other electrical/electronic-based systems, as well ascharacteristics that improve reliability of a system. Also covered are PLC characteristics that may create an unsafeoperating environment. Appendix B provides an overview of the use of programmable logic controllers inemergency shutdown systems. The intent is to familiarize the reader with the design, development, test, andmaintenance phases of applying a PLC to an ESD system. Each phase is described in detail and informationpertinent to the application of a PLC is pointed out.

iii

Contents

1. Introduction ............................................................................................................................................................... 11.1. Purpose ............................................................................................................................................................ 11.2. Scope .............................................................................................................................................. 2 ............... 11.3. Recom m endation and G uideline D efinition ................................................................................................... 11A . Structure of This D ocum ent ............................................................................................................................ 11.5. M otivation for This G uidance .......................................................................................................................... 21.6. Special K now ledge Required ......................................................................................................................... 2

1.6.1. A cronym s and A bbreviations ......................................................................................................... 21.6.2. Specialized Term inology ...................................................................................................................... 3

2. Project M anagem ent G uidance Recom m endations ............................................................................................. 42.1. Project M anagem ent Plan ............................................................................................................................... 42.2. Configuration Management Plan ............................................... 4

3. Safety G uidance Recom m endations ......................................................................................................................... 53.1. Safety Plan ...................................................................................................................................................... 53.2. Features Required for Safe Operation ....................................................................................................... 53.3. H azard and Risk A nalysis ............................................................................................................................... 53A . Failure Analysis .............................................................................................................................................. 53.5. Q uantification of System Reliability .......................................................................................................... 63.6. Quantification of System Availability ............................................ 63.7. Quantification of System Hazard Rate ................................ ............ 73.8. Software Reliability Issues ............................................................................................................................. 7

4. PLC Q ualification G uidance Recom m endations..; ............................................................................................ 84.1. H ardw are Q ualification ................................................................................................................................... 8

4.1.1. Environm ental and Class lE Requirem ents .................................................................................. 84.1.2. Com m unication System s ...................................................................................................................... 84.1.3. D ownloading Configurations to I/O M odules ................................................................................ 84.1A . Battery Back-Up of RAM ..................................................................................................................... 84.1.5. Circuit Protection on O utput M odules ............................................................................................. 94.1.6. 1/0 M odule Term inations ..................................................................................................................... 9

4.2. Softw are Q ualification .................................................................................................................................... 9

5. PLC Application G uidance Recom m endations ........................................................................................................ 10.5.1. PLC Configuration ....................................................................................................................................... 10

5.1.1. Real-Tune Perform ance ...................................................................................................................... 105.1.2. Formal Configuration Process ............................................ 105.1.3. Softw are M odularization .............................................................................................................. 115.1.4. Com m on Program m ing Languages ............................................................................................... 115.1.5. Com plex Instructions .......................................................................................................................... 115.1.6. Rem ote O perations ....................................................... : ..................................................................... 125.1.7. Software Style ..................................................................................................................................... 125.1.8. Latched O utputs .................................................................................................................................. 125.1.9. "Q ueue Full/Em pty" Indicators .................................................................................................... 125.1.10. Error H andling ................................................................................................................................. 12

5.2. Configuration Testing .................................................................................................................................... 135.2.1. Test Plan ............................................................................................................................................. 135.2.2. Failure D ocum entation ....................................................................................................................... 13

V

52.3. Software Verification and Validation ................................................................................................. 135.2.4. Software Fault Tree Analysis ....................................................................................................... 13

5.3. Installation ..................................................................................................................................................... 145.3.1. Installation Practice ............................................................................................................................. 145.3.2. Parallel Output Devices ...................................................................................................................... 145.3.3. Inductive Voltage Spikes .................................................................................................................... 145.3.4. Power Source Isolation ....................................................................................................................... 14

5.4. M aintenance ................................................................................................. ................................................. 155.4.1. Technical Specification Update ....................................................... .............................................. 155.42. D ocum entation of Failures ........................................................................................................... 155.4.3. PLC M odule Replacem ent ............................................................................................................. 155.4.4. Input/Output Forcing ......................................................................................................................... 15

5.5. M odifications ................................................................................................................................................ 165.5.1. M odifications ...................................................................................................................................... 165.5.2. On-Line Programm ing ........................................................................................................................ 16

vi

Contents-Appendix A: Programmable Logic ControllerCharacteristics and Safety Considerations

1. Introduction .............................................................................................................. 212. PLC Definition...................... ..................................................................................... 21

3. Intelligence ............................................................................................................... 213.1. CPU ................................................................................................................ 223.2. Memory............................................................................................................ 223.3. Operation .......................................................................................................... 223.4. Functionality ...................................................................................................... 22

3.4.1. Fundamental Functions.................................................................................... 243.4.2. Complex Functions........................................................................................ 26

4. Input Structure..................................................I........................................................... 304.1. Field Input Devices ............................................................................................... 304.2. 1/0 Module Terminations ........................................................................................ 304.3. Signal Conditioning............................................................................................... 304.4. Isolation............................................................................................................ 314.5. PLC Interface/Multiplex Electronics ............................................................................ 324.6. Indicators .......................................................................................................... 32

5. Output Structure........................;.................................................................................. 325.1. PLC Interface/Multiplex Electronics ............................................................................ 325.2. Signal Latching ................................................................................................... 325.3. Isolation............................................................................................................ 325.4. Signal Conversion ................................................................................................ 325.5. 1/0 Module Terminations......................................................................................... 345.6. Field Output Devices............................................................................................. 345.7. Indicators........................................................................................................... 34

6. Power Supply ............................................................................................................ 34

7. Communications.......................................................................................................... 357.1. System Fornats................................................................................................... 35

7.1.1. Master-Slave............................................................................................... 357.1.2. Peer-to-Peer......................................................................................... :....... 36

7.2. Components....................................................................................................... 367.2.1. Transmission Medium..................................................................................... 367.2.2. Interface Electronics....................................................................................... 367.2.3. Configuration .............................................................................................. 36

7.3. Error Handling.................................................................................................... 367.4. 1/0 Configurations................................................................................................ 37

7.4.1. Local .... i.................................................................................................... 377.4.2. Distributed .................................................................................................. 37

7.5. Capacity............................................................................................................ 378. Peripheral Devices........................................................................................................ 37

8. 1. Programming Terminals ......................................................................................... 378.1. 1. Modesof Operation ....................................................................................... 388.1.2. Select Commands.......................................................................................... 38

8.2. Select Devices..................................................................................................... 39

vii

9. P o r mm n .......Programming................................................................ 9...39. .B o ea.1.....................Boo....................e............................3.........39.2. Ladder Logic ...................................................................................................... 409.3. Sequential Function Charts....................................................................................... 409.4. Common Source Languages...................................................................................... 41

10. Special Features....;..................................................................................................... 4111. Failures................................................................................................................... 42

11.1. Stalling............................................................................................................ 4211.2. Instruction Mis-Execution ...................................................................................... 4211.3. PLC Memory........... ......................................................................................... 4211.4. Intermediate Memory ........................................................................................... 4311.5. 1/OAddress ...................................................................................................... 4311.6. 1/0 Module....................................................................................................... 4311.7. Infant Mortality.................................................................................................. 44

12. Redundancy .............................................. ........................... i................................... 4412. 1. PLC Processor.................................................................................................... 4412.2. 110................................................................................................................ 4512.3. Communications................................................................................................i46

13. Fault-Tolerant Systems ................................................................................................ 4714. PLC Classifications..................................................................................................... 48

Figures-Appendix A

Figure A-1. PLC Run-Time Operation.................................................................................... 23Figure A-2a. On-Delay Timer Operation.................................................................................. 25Figure A-2b. 0ff-Delay Timer Operation ................................................................................. 26Figure A-3. On-Delay Retentive Timer Operation ....................................................................... 27Figure A-4. PLC Input Structure........................................................................................... 31Figure A-5. Viso Test...................................................................................................... 32Figure A-6. PLC Output Structure......................................................................................... 33Figure A-7. Ladder Logic Program ........................................................................................ 40Figure A-8. Example Sequential Function Chart ......................................................................... 41

Figure A-9. A Failure Detection Technique Used in Output Modules .................................................. 43

Figure A-10. Dual Processor with Single 1/O ............................................................................ 45

Figure A-il1. Triple Processor with Single 1/O ........................................................................... 46Figure A-12. Dual Processor with Dual 1/0............................................................................... 47

Figure A-13. Triple Processor with Dual 1/0 ............................................................................. 49Figure A-14. Triple Processor with Triple 1/0 ............................................................................ 50

viii

Contents-Appendix B: Application of Programmable LogicControllers in Safety Shutdown Systems

1. Introduction ............................................................................................................................................................. 55

2. Scope ....................................................................................................................................................................... 55

3. Docum entation ........................................................................................................................................................ 55

4. PLC Life Cycle Issues ............................................................................................................................................. 564.1. Project M anagem ent ....................................................................................................................... ? ............. 564.2. Safety Analysis ............................................................................................................................................. 57

4.2.1. Safety Considerations ......................................................................................................................... 574.2.2. Availability ........................................................................................................................................ 604.2.3. Hazard Rate ......................................................................................................................................... 61

4.3. The PLC-Based ESD System ........................................................................................................................ 614.3.1. HardwareSelection ............................................................................................................................. 614.3.2. Software Development ....................................................................................................................... 614.3.3. PLC-Specific Considerations ....................................................................................................... 62

4.4. Testing ........................................................................................................................................................... 624.4.1. Hardware Test ..................................................................................................................................... 624.4.2. Software Test ...................................................................................................................................... 634.4.3. System Integration .............................................................................................................................. 634.4.4. System Test ......................................................................................................................................... 634.4.5. System Final Acceptance Test ..................................................................................................... 63

4.5. Installation .................................................................................................................................................... 634.6. M aintenance .................................................................................................................................................. 65

4.6.1. Hardware M aintenance ....................................................................................................................... 654.6.2. Software M aintenance .................................. ..................................................................................... 65

4.7. M odifications ................................................................................................................................................ 664.7. 1. Hardware ............................................................................................................................................. 664.7.2. Software .............................................................................................................................................. 66

5. Com parative Design Im plem entations ............................................................................................................... 665.1. Electrical System- Relay Based ............................................................................................................ 675.2. Electronic System - Solid-State Based .................................................................................................. 695.3. Program m able Electronic System- PLC ............................................................................................... 70

6. Application Examples ............................................................................................................................................. 746.1. All Side Construction, Inc ............................................................................................................................. 746.2. Flour Daniel, Inc ............................................................................................................................................ 746.3. General Electric ............................................................................................................................................. 756.4. PLC Structured Program ming ....................................................................................................................... 756.5. PLC Qualification Testing ............................................................................................................................ 766.6. PLC Software Bug ........................................................................................................................................ 766.7. PLC Safety Concerns ................................................................................................................................... 77

7. Rem arks ................................................................................................................................................................... 79

References .................................................................................................................................................................... 81

ix

Figures-Appendix B

Figure B-i. Engineering and Test Flow D iagram .................................................................................................. 58

Figure B-2. A vailability Com ponents ........................ 6.0............................................................................................... 60

Figure B-3. Piping and Instrum ent D iagram ......................................................................................................... 67

Figure B-4. Relay W iring D iagram ............................................................................................................................. 68

Figure B-5. Solid-State W iring D iagram .................................................................................................................... 69

Figure B-6. Solid-State Logic D iagram ...................................................................................................................... 70

Figure B-7. PLC W iring D iagram ............................................................................................................................... 71

Figure B-8. PLC Ladder Logic D iagram .............................................................................................................. 72

Figure B-9. PLC System ............................................................................................................................................. 73

Table 1. Dangerous Failure MTBF of Various PLC Systems .............................................................................. 77

Table 2. Availability of Various PLC System s .................................................................................................... 78

Table 3. Hazard Rate of Various PLC System s .................................................................................................... 78

x

The Programmable LogicController and Its Application

in Nuclear Reactor Systems

1. INTRODUCTION

1.1. PurposeThe purpose of this document is to outlinerecommendations for guidance for the review ofapplication of Programmable Logic Controllers (PLCs)to the control; monitoring and protection of nuclearreactors. Several characteristics set PLCs apart fromother programmable electronic systems (PESs) orcomputer systems: they use a deterministic operatingsystem, their primary interfaces are digital and analogsensors and actuating devices, and they typically allowprogramming to be done with ladder logic diagrams.These diagrams allow the design of the logic of thesystem to proceed using the traditional ladder logicmethod of expressing the logic of the system.However, as these systems have evolved, they havebegun to include other progmammning methods. PLCsystems are beginning to resemble other general-purpose industrial digital control systems as thedistinctions between them have begun to blur.

Because of this trend toward making PLCs; moreflexible, the methods employed to d esign and installthese systems are tending toward those used in otherprogrammable systems. Thus, the guidancerecommended below will resemble the guidance whichshould be used for more general-purposeprogrammable systems.

1.2. ScopeIn order to make programmable systems more flexibleand easier to use for those who are not proficient withprogramming languages, industry has developedconfigurable systems such as PLCs. Configurablesystems provide a unique approach to designing a PESin that a user of the system selects hardwarecomponents and programs the system using arestricted, very-high-level language (referred to as"configuration") to build a system. Configurable

systems make implementation of a nuclear power plantprotection system easier tha it would be if a non-configurable microprocessor-based system was used.This document addresses PLC-based protectionsystems only.

For a PLC-based protection system two organizationswill produce the software and design the hardware-the protection system engineering organization and thePLC manufacturing organization. Guidance concernsare addressed in this document for both organizations.The protection system organization selects the PLCand establishes the protection system requirements,while the PLC manufacturer's organization isconcerned with providing a system that appeals to itscustomers. Since most of the PLC orders come fromindustry (i.e., auto, food processing, petrochemical),the PLC manufacturer accommodates industry's needs.However, these needs may not correspond to the needsof a nuclear power plant protection system.

1.3. Recommendation and GuidelineDefinitionSuggested guidance is provided in this documentbeginning with Section 2. Each suggestion consists of atitle, motivation or technical basis, and the guidance.The guidance takes the form of either arecommendation or a guideline. For this report, arecommendation is an item that is important to thesafety of the system while a guideline is goodengineering practice that should be followed toimprove the overall quality, reliability, orcomprehensibility of the system.

1.4. Structure of This DocumentThis document provides suggested recommendationsand guidelines for PLC applications in nuclear plantprotection systems. The topics should be addressed by

Section 1. Introduction

the design team in the same order that they appearbelow.

Section 2 begins with project and configurationmanagement issues. Section 3 addresses the safety-specific concerns involved in the project. Section 4covers the guidance necessary to ensure that the PLCplatform is qualified, including the manufacturer'sdesign, development, tests, maintenance, andmodification procedures. The PLC platform consists ofthe PLC hardware, the operating system, and allsoftware used to develop the application software.Basically, the platform is all the items a user can buy"off the shelf' from a PLC manufacturer. Finally,Section 5 covers the activities necessary to configure,test, install, maintain, and modify the PLCconfiguration for the plant protection system.

Appendices A and B provide background informationfor readers wishing more information about PLCs.Appendix A describes a generic PLC and highlightsthe characteristics important to safety. Appendix Baddresses the life cycle of selecting, applying andmaintaining a PLC system.

1.5. Motivation for This Guidance

Nuclear power plant utilities are upgrading relay-basedsystems with PLCs. Some utilities are implementingthis upgrade without prior NRC review and approval.1OCFR50.59 allows the licensee to make changes inthe nuclear power plant facility without NRC reviewand approval prior to implementation provided thechange does not involve an unreviewed safetyquestion. A change is considered an unreviewed safetyquestion if:

(1) The probability of occurrence or the consequenceof an accident or malfunction of equipmentimportant to safety previously evaluated in theSafety Analysis Report may be increased.

(2) The possibility for an accident or malfunction of adifferent type than any previously evaluated in theSafety Analysis Report may be created.

(3) The margin of safety as defined in the basis forany Technical Specification is reduced.

For most changes the probability of item (1) isperceived as reduced, which is acceptable. For a PLC,this probability can not be quantitatively determinedwith any confidence. Thus the argument for item (1) issubjective.

When changing from a relay-based or solid-state-basedsystem to a PLC system, item (2) is an unreviewedsafety question. The software in the PLC presents adifferent type of failure mode that could not have beenevaluated in the aforementioned type of systems. Inaddition, a single failure in the PLC central processingunit (CPU) has the potential to degrade a larger portionof the system than any single failure of a relay or solid-state device.

Item (3) may be an unreviewed safety question,because the surveillance, limiting conditions ofoperation, and/or channel definitions defined in theTechnical Specifications may not apply to a PLC-basedsystem. For surveillance, a functional test is sufficientfor a relay-based system, but a functional test is notadequate to determine if a PLC-based system isfunctioning properly. PLC-based systems use self-diagnostics, which must be considered whendeveloping surveillance requiremefits. The limitingcondition of operations for a CPU being out of servicewill be different from that of a relay or solid-statedevice. The CPU may degrade many functions whilethe relay or solid state device may degrade only one. Ifthe PLC-based system relies extensively onmultiplexing and communication networks, thenchannel definitions will probably differ from relay-based or solid-state systems.

New advanced light water reactors (ALWRs) are beingproposed that incorporate PLC-based control andprotection systems. The NRC has chosen to take thelead in proposing the much-needed guidance for theALWR vendors, utilities, and regulators on the use ofPLCs in nuclear power plant protection systems.

The main body of this document provides theexperienced engineer with a review of safety issues inPLC-based systems, while Appendices A and Bintroduce an inexperienced engineer to PLCs and theuse of PLCs in safety applications.

1.6. Special Knowledge Required

1.6.1. Acronyms and Abbreviations

BPCSCMFACPUCRCDCS

EMIESD

Basic Process Control SystemCommon-Mode Failure AnalysisCentral Processing UnitCyclic Redundancy CheckingDigital Control SystemElectromagnetic InterferenceEmergency Shutdown

NUREG/CR-6090 2

. Section 1. Introduction

FMEA

FTAHWCII/O

LEDLRC

MDT

MTBFMTDFMTDLMTRFMTROMTIR

PCPESPIDPLC

RAMROM

SCADASFCSFTA

SWCITMR

UPSVRC

Failure Mode and Effects AnalysisFault Tree AnalysisHardware Configuration Item

Input and Output

Light Emitting DiodeLongitudinal Redundancy Checking

Mean Downtime

Mean Time Between FailuresMean Time to Diagnose FailureMean Time to Determine Fault LocationMean Time to Replace a Faulted ComponentMean Time to Return to Operable ConditionMean Time To Repair (MTDL + MTRF +MTRO)Personal ComputerProgrammable Electronic SystemProportional/Integral/Derivative

Programmable Logic ControllerRandom Access MemoryRead-Only Memory

Supervisory Control and Data AcquisitionSequential Function ChartsSoftware Fault Tree AnalysisSoftware Configuration ItemTriple-Modular Redundant

Uninterruptible Power SourceVertical Redundancy Checking

bits in a numeral, or group of numerals, usuallywithout regard to meaning, position, orsignificance. Modified IEEE Std. 100-1988definition.

Control network. The PLC communication networkwhich connects the PLC processor to the 1/0modules.

Cyclic redundancy check. An error-detection thatintroduces a check sum at the end of a group ofcharacters that constitute a message. CRC is apopular error-checking scheme in communicationsystems.

Down time. A period of time that a system isunavailable. Downtime does not include the periodof time in which the plant is down formaintenance.

Fail-safe. Fail-safe refers to the output action of acontrol system upon a failure. A fail-safe controlsystem is one whose outputs operate in such amanner as to reduce the risk of accident when acomponent or circuit failure occurs in the controlloops associated with that failure.

Fail-safe faults. A fault that immediately causes thesystem to go into a safe state or, in a redundantsystem, a fault which does not prevent proper andsafe control of the process.

Fail-to-danger faults. A fault that prevents thecontrol system from responding to hazardwarnings, or can cause a hazardous condition.

Failure mode and effects analysis. A systematicprocedure for identifying the modes of failure andfor evaluating their consequences. The essentialfunction of an FMEA is to consider each majorpart of the system, how it may fail (the mode offailure), and what the effect of the failure on thesystem would be (the failure effect) (IEEE-352).

Fault tree analysis. A technique, either qualitative orquantitative, by which failures that can contributeto an undesired event are organized deductively ina logical process and represented pictorially. It isone way to diagram and communicate theinformation developed in a failure mode andeffects analysis (FMEA) (IEEE-352).

Ladder logic diagrams. Drawings which usesstandard symbols (e.g., ISA S5. I-InstrumentSymbols and Identification) to designatemeasurement, logic, and control systeminterconnections.

1.6.2. Specialized Terminology

Availability. (4) (General) The fraction of time thatthe system is actually capable of performing itsmission. (5) (software) (A)The degree to which asystem or component is operational and accessiblewhen required for use. (B) The ratio of system up-time to the total operating time. (C) The ability ofan item to perform its designated function whenrequired for use. (7) (nuclear power generatingstation) (A) The characteristic of an itemexpressed by the probability that it will beoperational at a randomly selected future instant intime. (B) Relates to the accessibility ofinformation to the operator on a "continuous,""sequence" or "as called for" basis. IEEE Std.100-1988 definition.

Checksum. A deterministic function of a file's ormemory's contents. If a file is copied and thechecksum of the copy is different form theoriginal, there has been an error in copying. Thechecksum value is a sum obtained by adding the

3 NUREG/CR-6090

Section 1. Introduction

Ladder logic. Symbolic programming language usedon PLCs. The symbols used in the program relateto ladder logic diagram symbols.

Longitudinal redundancy checking. An error-detection scheme that introduces a single checkingcharacter at the end of a group of characters thatconstitute a message.

Macro. A macro resembles a program subroutine inits use but in the implementation, code is actuallycopied into the program each time the macro iscalled. Thus there is no transfer of control fromone routine to another each time the macro is used.

Processor-to-processor network. A high-speedcommunication network which connects PLCprocessors to other PLC processors, computers,main-frames, etc.

Programmable electronic system. Any computer-based system which controls, protects or monitorsthe operation of plant machinery or various typesof equipment via plant sensors and actuators.

Proportional/Integral/Derivative. Process controlalgorithm typically used for control of flow,pressure, and liquid level.

Plant safety. An acceptable low risk that a system willmaintain plant parameters within acceptable limitsestablished for a design basis event.

Reliability. (1) (general) (B) The probability that adevice will function without failure over aspecified time period or amount of usage. Notes:(1) Definition (B) is most commonly used inengineering applications. In any case whereconfusion may arise, specify the definition beingused. (2) The probability that the system willperform its function over the specified time shouldbe equal to or greater than the reliability. IEEEStd. 100-1988 definition.

Sequential function charts. Object-orientedprogramming language used to program PLCs.

System network. The PLC communication networkwhich connects peripherals to the PLC processor.The connection is made through the PLCprocessor module or a special I/O module.

Vertical redundancy checking. An error detectionalgorithm also known as parity checking.

2. PROJECT MANAGEMENTGUIDANCERECOMMENDATIONS

2.1. Project Management Plan

An important element in a successful project is goodproject management. MIL-STD-499A and IEEE-1058.1 outline a technical and managerial process todocument and control a project. A comprehensiveprocess needs to be thought out and written before theproject begins. Some projects employing PLCs may berelatively small (one PLC), in which case the planmentioned here may be the overall organizational planof the site. It is not necessary that a special plan beproduced for each project. It is important, however,that not too much informality be used forimplementing a PLC system, even if it is a smallsystem.

Recommendation:

The utility should have a written project managementplan in force which details the project organization,responsibilities, managerial process, technical process,tasks, schedule, and budget. This plan may be as shortas one page for a small project, and as large as severalhundred pages for bigger projects.

(See Appendix B, Section 4.1 for a discussion of projectmanagement.)

2.2. Configuration ManagementPlan

All projects, including those containing PLCs, canbenefit from good configuration management. Severalstandards (MIL-STD-483A, MIL-STD-1456A, MIL-STD-1521B, IEEE-828, and IEEE-1042) address thisissue. Through implementation of these standards, thedecisions and changes made over the life of the projectcan be well controlled and documented.

Recommendation:

The utility should have a software and hardwareconfiguration management plan documented and inforce. This plan should largely conform either to one ofthe standard systems listed above or another acceptablestandard.

(See Appendix B, Section 4.1 for a discussion ofconfiguration management.)

NUREG/CR-6090 4

Section 3. Safety

3. SAFETY GUIDANCERECOMMENDATIONS

3.1. Safety Plan

As it is important toplan the complete life cycle of asystem, beginning with the original conception andcontinuing to decommnissionin'g, it is equally importantto define a safety life cycle when safety is an importantissue. The safety life cycle model is a part of a safetyplan. During the system requirements phase of theproject, the safety plan is developed in outline form.Throughout the remainder of the project the safety planis completed and updated. The life cycle model showsthe phases of the project that require safety specificactivities. The IEG is developing a standard (IEC-65A)that addresses safety issues for programmable systems,and specifically addresses the safety plan and thesafety life cycle model.

Recommendation:

The utility should generate documents detailing thedesign requirements from a safety perspective. Also, asafety life cycle model needs to be developed as part ofthe overall system life cycle.

3.2. Features Required for SafeOperation

Specific features of the system that are required forsafe operation must be clearly delineated. To helpfocus on safety and provide a decision path for others,the reason each feature is important to safety should bestated. Some features which should be considered forPLC systems are:

* Module "hot swapping."

* RAM battery back-up and battery monitor.

* System battery back-up.

* Redundancy.

* Fault tolerance.

* Acceptable system availability.

* Clearly defined fail-safe modes.

Recommendation:

Specific features of the system that are required forWae operation are to be identified and the reason they

a= important to safety needs to be documented.

(See Appendix A for additional information on PLCfeatures.)

3.3. Hazard and Risk Analysis

A safety analysis should be performed that identifiesthe hazards and risks that the system will have tomitigate. Once the hazards and risks are identified thesafety function can be defined. The system response toeach hazar and risk must be clearly specified.Document IEC-65A discusses the objectives andrequirements of a hazard and risk analysis.

Recommendation:

The hazards and risks identified and the safetyfunctions that are necessary to mitigate them need to bespecified. The hazard and risk analysis identifies thehazards, defines the event sequence leading up to eachhazard, and determines the risk associated with eachhazard. For each anticipated hazard or risk the system'sresponse should be described and found acceptable.

(See Appendix B, Section 4.2 for a discussion of safetyanalysis.)

3.4. Failure Analysis

Failure analysis is an activity that will be completedbefore the selection of the ESD system (to establishthat the system can meet the performance goals) andverified after engineering and installation. In thesystem requirements phase of the project, an outline ofthe Safety Plan should be developed, and that outlineshould call out the need for this activity.

An important exercise in producing a safe system is toanalyze the system to find unsafe states. Bysystematically identifying these states, the systemdesigners should be able to re-design in order to reducethe number of unsafe states and prove acceptability ofany remaining unsafe states. Some potential problemsto be considered are:

Power transients, excursions, and dips.

Auto-recoveries from power loss.

Initialization routines for PLC system start-up.

Shutdown routines for the PLC system.

Memory loss or corruption.

Communication loss or corruption.

I/0 module failures.

5 5 NURE-GICR-6090

Section 3. Safety

* Unreadable or unread inputs.

• Addressing errors.

" Processor faults, both in the PLC CPU and the 110modules' CPU.

The FMEA and FRA (IEEE-352) are tools that can beused to systematically analyze failures of a system andthe effects of those failures. Common-cause failuresare less frequent than single failures (which areanalyzed in an FMEA or FTA) but can be much moresevere. EPRI has written a document, EPRI NP-5613,which addresses the issues of adding common-causefailure effects into an FMEA or FTA.

A PLC system can be thought of as having two majorcomponents-software and hardware. The techniquesmentioned above are easily applied to hardware, butcharacterizing reliability for software is much moredifficult. The analyses mentioned here typically willnot include software unless there is a solid statisticalbasis for quantifying the software reliability.

Guideline:

A parametric model of the PLC system should bedeveloped and used to quantify the probability ofsystem failure.

(See Appendix B, Section 4.2 for a discussion of safetyRecommendation: analysis.)

Failures that put the system into unsafe states are to bedetermined, and ways to reduce the number of theseunsafe states should be explored. Single failures andcommon-cause failures should be analyzed.


3.5. Quantification of SystemReliability

Quantification of system reliability is an activity thatwill be completed before the selection of the ESDsystem (to establish that the system can meet theperformance goals) and verified after engineering andinstallation. In the system requirements phase of theproject, an outline of the Safety Plan should bedeveloped, and that outline should call out the need forthis activity.

Various reliability analysis techniques are available.Both qualitative and quantitative methods can be usedto gain a better understanding of the system and ahigher confidence that the system will perform itsrequired functions.

Many parametric modeling techniques are availableand can be used to quantify the reliability of hardware.One group in particular, ISA Subcommittee SP84.02,has done extensive work modeling PLC systems andquantifying the reliability of the hardware. Thiscommittee has written a document, ISA SP84.02,which uses Markov models to quantify the reliabilityof 14 different PLC architectures. EPRI documentEPRI NP-5613 references other parametric modelingtechniques that can be used to quantify reliability ofhardware systems.

3.6. Quantification of SystemAvailability

Quantification of system availability is an activity thatwill be completed before the selection of the ESDsystem (to establish that the system can meet theperformance goals) and verified after engineering andinstallation. In the system requirements phase of theproject an outline of the Safety Plan should bedeveloped, and that outline should call out the need forthis activity.

Calculating an availability number along with theestimated hazard demand on the system can bevaluable in estimating system safety. Typically, theinfluence of software on availability is not factored inbecause of the difficulty of quantifying softwarereliability.

Guideline:

The method of calculating the desired availability ofthe system should be clearly documented. Estimates ofthe various constituents of availability need to be madeand documented. In addition, the desired systemavailability needs to be determined. The acceptableavailability will depend heavily on the desired hazardrate. It is important to document all steps performedand decisions made to reach the availability number.Also, any changes should be documented, along withreasons for making the changes.

NUREG/CR-6090 6

Section 3. Safety

3.7. Quantification of SystemHazard RateQuantification of system hazard rate is an activity thatwill be completed before the selection of the ESDsystem. At the system requirements phase of theproject an outline of the Safety Plan should bedeveloped, and that outline should call out the need forthis activity.

Hazard rate is a measure that relates the systemavailability and reliability to the concerns of safety.How low the hazard rate should be can only bedetermined by acceptable industry standards, thepeople at risk, and the plant managers. Of course, thehazard rate can not equal zero, but neither should thehazard rate be entirely unacceptable by any of thegroups mentioned above..

Guideline:

The process of determining the acceptable hazard rateand the means to achieve it should be clearly indicatedin the documentation of the safety analysis.


3.8. Software Reliability IssuesDetermination of software reliability should becompleted after software has been written. In thesystem requirements phase of the project an outline ofthe Safety Plan should be developed, and that outlineshould call out the need for this activity.

The techniques discussed above can easilyaccommodate hardware, but applying them to softwareis a much more difficult task and they are rarely, ifever, used for this purpose. Nancy Leveson of U.C.Irvine has been doing some work with software faulttree analysis (SFTA). She presents a procedure basedon FrA techniques to improve the reliability and safetyof the code. Although FTA is quantitative, SFTA isqualitative. The SFTA breaks each hazard down tosoftware components. Once these components areidentified, the developer can act to reduce the numberof hazards. More detailed information on SFrA andexamples of its use can be found in Leveson andHarvey 1983 and Leveson et al 1991.

Formal Methods can improve software reliability andare getting much attention in the software community.

Ladder logic lends itself to Formal Methods. Theapproach of Formal Methods is to derive mathematicalequations for the system outputs in terms of the systeminputs. Ladder logic programming (assuming nocomplex function blocks are used) is convertible intoBoolean equations. Thus, if the system requirementsare defined with Boolean equations, a comparison ofsystem level Boolean equations and ladder logicprogram Boolean equations can be made.

Guideline:

It is useful to express the ladder logic to beimplemented in Boolean equation form prior toimplementation. This could be the language of therequirements document. After implementation theequations could be re-derived from the ladder logic,taking into account the idiosyncrasies of theimplementation that the PLC imposes. As a check, theBoolean equations derived from the ladder diagramscan be compared to the equations used to specify theladders. The person deriving the equations from theladder should be different from the person whoperforms the implementation from the equations andfrom the person who produced the equations in the firstplace.

If other programming languages are used (C, forexample), the standard methods for softwareverification and validation (V&V) should be employed,together with good programming practice (such asinspections).

(See Appendix B, Section 4.3.2 forfurther discussion ofsoftware concerns.)

7 NUREG/CR-6090

Section 4. PLC Qualification

4. PLC QUALIFICATIONGUIDANCERECOMMENDATIONS

Section 4 deals with qualification of the manufacturer'shardware and software. It specifically excludes allapplication software which may be written in LadderLogic language, state-based language, SequentialFunction Chart language, Boolean language,configuration tables, or any other configurable systemlanguage. Protection system application software forthe PLC system that is written in C, BASIC, or anyother common source language is also not treated inthis section.

4.1. Hardware Qualification

4.1.1. Environmental and Class 1ERequirements

PLCs must be able to perform reliably in theenvironment in which they will be installed.

Recommendation:

A PLC system for use in a reactor protection systemshould be qualified as a Class IE system.

4.1.2. Communication Systems

Most PLC systems can communicate over many typesof media with various communication protocols. Anysystem that communicates with the PLC system cancause the PLC system to "lock up." A partial listincludes devices such as printers and cassette loaders,as well as systems using one-way messages to othersystems that incorporate "hand-shaking" or errorcorrection techniques. The issue of reliablecommunications is a complex topic and requires adetailed understanding of the communication systemsand understanding of the safety implications imposedon the protection system via communication failures.Preckshot 1993b discusses the current state of digitalcommunication systems. In addition, Preckshot 1993bprovides recommendations and guidance oncommunication systems for nuclear power plantapplications.

Recommendation:

All communication systems in the PLC-based PESshould adhere to the recommendations and follow theguidelines of Preckshot 1993b.

(See Appendix A, Section 7for a discussion of PLCcommunications.)

4.1.3. Downloading Configurations to 110Modules

The current trend in configurable electronics is to havethe host device (e.g. the PLC CPU or a programmingterminal) download configurations to I/0 modules.One potential problem that must be addressed in thiscase is the question of whether the configuration willsurvive a power failure. If it will not, then the moduleshould have a means of indicating the configurationloss to the PLC. The PLC user program must thensense the module's memory loss and reload theconfiguration. It should be noted that 1./0 modules areusually located remotely from the PLC and are notnecessarily subject to the same power losses to whichthe PLC is subject. Therefore, it is not sufficient tomonitor only power loss at the PLC itself.

Recommendation:

Special consideration should be given to PLC systemshaving 1/0 modules that store configurationinformation in RAM. The hazards and risk of losingdata from or having corrupted data in the 1/O module'sRAM must be evaluated and documented in the SafetyPlan. In addition, other safety considerations such aspower loss and automatic re-start must be addressed inthe Safety Plan.

(See Appendix A, Section 8.1 for more information on

programming concerns.)

4.1.4. Battery Back-Up of RAM

Most PLC systems contain volatile RAM in the PLCCPU and there also may be volatile RAM in variousI/O modules. This RAM loses its memory upon loss ofpower. In order to retain memory through systempower outages, PLC systems have battery back-up.Typically, the battery's life will be several years.

To facilitate maintenance of these batteries, mostmanufacturers provide indicators to warn the operatorswhen a battery is near failure. Typically, the PLCsystem is in a cabinet and the only way to see a localindicator is to open the cabinet doors. It is much betterif the PLC manufacturer provides the capability toremotely indicate the low-battery status. If I/O moduleshave a backup battery, then the module shouldannunciate their impending failure to the PLC, whichwill then take the appropriate action.

NUREG/CR-6090 8

Section 4. PLC Qualification

Recommendation: 4.2. Software Qualification

The PLC system should have a means to report to theoperators and maintenance personnel low batterypower on all RAM back-up batteries. Administrativeprocedures and checklists are the minimum necessaryfor monitoring battery life.

(See Appendix A, Section 6 for more information onpower supplies.)

4.1.5. Circuit Protection on OutputModules

Most output modules that switch power to field deviceshave equipment such as fuses or circuit breakers toprotect the output electronics. When these circuitprotectors trip they eliminate the output module'scapability to control the field device.

Recommendation:

All 1/0 points with circuit protection should be undersurveillance.

(See Appendix A, Section 5Sfor more information on

output structures.)

4.1.6. 1/0 Module Terminations

1/0 module terminations provide the interconnectionbetween the field input/output devices and the PLCsystem. These terminations are available in a variety ofdesigns and configurations. To maintain the integrity.of the connections over the life of the equipment, (1)the I/O modules of the PLC system should beremovable without disturbing the field wiringconnections, and (2) there should be a mechanism toensure that the field connections will not loosen overthe life of the equipment.

Guideline:

The PLC system should allow 1/0 module removalwithout disconnecting any of the field wiring. Further,the field wiring terminations should lock down in amanner that will not allow the wires to loosen over thelife of the equipment.

Finding methods to prove the safety and reliability ofsoftware is an elusive goal that is being sought bymany people in the software community.

The software provided by the PLC manufacturershould meet all of the standards applying to softwareused in the intended application, which requires thepurchaser of the software to inspect the process that thePLC vendor uses in the production of the software toverify that there is a software management plan, aconfiguration management plan, a QA plan, a V&Vplan, etc., all in place, in force and being executed.Further, these plans should be equivalent to those thatwould be required for any software produced and usedin the intended application.

A weak alternative to the above is the process of"commercial dedication," in which a software vendorhas enough experience with the software in actual useto justify the assertion that the software is sufficientlyreliable for the intended application. This experienceshould include a method for receiving problem reportsfrom the field and then resolving them throughmodifications when appropriate. There should al 'so be amethod for proving that changes, when made, in factimprove the system and do not install other errors. Thismay be determinable through regression testing. Notethat an organization that can successfully handle thistask (resolving problems) probably has a reasonablygood method for developing software in the first place.

The best evidence of qualification is that both of theabove alternatives are available.

Recommendation:

PLC manufacturers should be able to demonstrate tothe purchaser that they are using good softwareengineering practice to produce their software, and thatthe software is sufficiently reliable to meet therequirements of the intended application. Alternatively,they should be able to show that there is adequateexperience in actual operation of the proposed softwarein the field to demonstrate that the reliability of thesoftware is adequate for the intended application.

(See Appendix B, Section 4.3 for further discussion ofPLC considerations.)(See Appendix A, Sections 4 and Sfor more

information on input and output structures.)

9 9 NUREGICR-6090

Section 5. PLC Application

5. PLC APPLICATIONGUIDANCERECOMMENDATIONS

5.1. PLC ConfigurationSection 5 addresses the configuration of the PLChardware and software. The software may be written inLadder Logic, state machine language, SequentialFunction Chart language, Boolean language,configuration tables, or other configurable systemlanguage. Application software written in C, BASIC,or other common source language is also addressed inthis section.

5.1.1. Real-Time Performance

Real-time performance is of utmost importance for aprotection system. The system must be able to respondto a hazard within a specified time. A worst-casetiming analysis would be appropriate after thehardware configuration is complete and beforeimplementation. This analysis, followed by a timidngtest, could prove the system meets all the real-timerequirements. Lawrence 1992b address real-timeperformance issues relative to protection systemapplications.

Recommnendation:

The real-time performance requirements of the systemshould adhere to the recommendations and follow theguidelines of Lawrence 1992b.

5.1.2. Formal Configuration Process

Software development, regardless of the languageused, benefits from the application of a formal process.A requirements document should be produced thatcontains al of the requirements the system must meet.For instance, if ladder logic is to be the language ofimplementation, Boolean equations provide a clear,unambiguous method of specifying what must beaccomplished, but Boolean equations alone areinadequate. Clear, natural-language specificationsshould be included, whatever method is used, in orderthat details of the requirements can be made clear tofuture readers. Each requirement should be testable sothat the implementation can be validated whencompleted. Untestable statements iii the requirementsdocument are not requirements and only addconfusion.

Once the requirements documents have been inspectedand approved by an appropriate authority, design mayproceed. This inspection and approval processcorresponds to requirements verification in the moreconventional software world. For PLC applications,design and implementation may blend together in sucha way that the two operations become inseparable, yetthere should be a document that contains the completedesign, even if it looks like an implementation. Relyingon a soft copy in the implementing machine isinadequate. Further, a document is needed that mapsthe input and output modules to the field devices towhich the modules are connected.

Next, appropriate reviews and inspections of the designand implementation must be performed in order toeliminate errors before starting the test activity. Thesereviews and inspections correspond to independentverification of the software. Reports should be issued*to document the inspections and reviews performed,deficiencies found and remedial action taken.

Prior to installation, the system should be "rung out!'and tested to verify that the system meets all of itsrequirements. This step corresponds to softwarevalidation in more conventional software systems. Testplans and procedures need to be written and test resultsdocumented showing any deficiencies discovered andremedial action taken.

When the installation is complete, an integration testshould be run to demonstrate that the connections areall correct and that the installation is complete. Testplans and procedures need to be written and test resultsdocumented showing any deficiencies discovered andremedial action taken.

Finally, all of the above mentioned documents shouldbe updated to represent the system as built, and theyshould all be put under configuration control.

Thle process described above applies to systemsconsisting of one or two PLCs connected to somehardware. As more complex systems are contemplated,more formal methods should be applied, up to the pointat which a full-blown project management system is inplace, including a full formal software developmentplan and life cycle. The auditor should tailor his auditto the complexity of the system. Simple systems shouldrequire simple plans and simple documentation, whilecomplex systems should be planned and documentedaccordingly.

NUREG/CR-6090 110


Recommendation:

Plans and documentation need to be produced that areappropriate to the size of the system being built. Theseitems should be complete, accurate, and should clearlyindicate that a process adequate for the application wasused in the production of the software.(See Appendix Bfor a discussion of PLC

considerations.)

5.1.3. Software Modularization

In many cases, certain functions appear repeatedly inan implementation. For example, circuits to start andstop motors may appear several times in a system. Forsuch functions, standardized configurations should beproduced and used whenever appropriate.Modularization of the software configuration makesthe software easier to read, understand, and test.

Guideline:

To the extent possible, the configuration of thesoftware should be modularized into functional blocks.

(See Appendix A, Sections 4 and 5for more

information on input and output structures.)

5.1.4. Common Programming Languages

Many manufacturers are providing the ability toprogram their PLCs or their 1/0 modules with commonprogramming languages (C, BASIC, FORTRAN, etc.)or some dialect of these languages. The manufacturerprovides all the necessary features to incorporate auser-programmed subroutine. For ladder logic a"program block" is provided in which a user-programmed subroutine can be written. The subroutinehas direct control over the PLC processor's registersand performs read, write, and computationaloperations. The program block has an input to start thesubroutine and status outputs that can be used tocontrol other ladder logic instructions. One of theadvantages of a PLC over a more conventionalcomputer system is that the programming language is avery-high-level language aimed at a specificapplication (e.g., ladder logic). The introduction ofconventional computer languages compromises thatsimplicity. Another advantage of the PLC executingonly ladder logic is that the program scan isdeterministic. With the introduction of program blocks,the system may become non-deterministic. Further,program blocks may allow the user to read or write to

any RAM location in the PLC. Typically, theprogrammer only manipulates the PLC processorregisters, but it may be possible to manipulate vitalareas of RAM such as the configuration data, 1/0mapping data, or I/O image tables. Thus, usingcommon programming languages in a PLC allows theprogrammer to completely subvert the operatingsystem and the interpreter with, perhaps, disastrousconsequences.

Recommendation:

When common programming languages are used in thePLC system, documentation and development methodsshall be employed that are adequate for the safetycriticality of the application.

(See IEC-880, IEEE/ANS P-7-4.3.2, or Preckshot

1993c for more information.)

5.1.5. Complex Instructions

Certain instructions can be misused or their effects canbe overlooked, due to the complexity they add to thesoftware. Ladder logic instructions such as JUMP,GOTO, SKIP, or interrupts (e.g., Processor InputInterrupts-this instruction/function interrupts the PLCCPU and executes a ladder logic subroutine) areexamples. This is a difficult area because the subtleeffects of these instructions may be overlooked. Thus,problems that may occur must be considered whileemploying these instructions. The possibility of anerror occurring is particularly likely over the long term.For instance, the original programmer may use a subtleinstruction without documenting it carefully enough,and then a later programmer making a modificationcauses a system failure because he did not recognizethe effect of the subtlety. Further, each PLC vendorprovides a different set of commands, which furthercompounds the problem of added complexity.

Recommendation:

The implementation should be as simple as possible,avoiding complex data structures, program blocks,instructions with concealed side effects, etc. It shouldbe possible to look at a sample of the code to see ifsuch elements are employed.

(See Appendix A, Section 3.4.2for more information oncomplex functions.)

11 11 NUREGICR-6090


5.1.6. Remote Operations

Some PLCs allow control of the software configurationvia remote computers using communication links. Theremote computer can change the PLC configuration,force outputs to particular states, and change the modeof the PLC (e.g. from "run" to "stop"). If this type ofoperation is allowed at all, it should be under strictcontrol.

Recommendation:

Remote operation of any PLC should be allowed onlywith written approval, for a strictly limited anddocumented period of time, for a specific purposespelled out in the approval document, and under strictsupervision.

(See Appendix A, Section 8.1 for more information on

remote operations.)

5.1.7. Software Style

When writing software for safety-related applications,considerable effort should be expended to producecode that is as clear as possible. Writing compact and"efficient" code should be dispensed with if itinterferes with clarity. This effort is particularlyimportant for nuclear systems, whose lifetimes areseveral decades. It is unreasonable to expect that theprogrammer who originally programmed anapplication will be present to maintain it near the endof its life. The several people who have responsibilityfor the code over its life need to have a code that canbe easily understood.

Guideline:

Every attempt should be made to configure thesoftware in a manner that is easily understood.Understandability of the configuration should be atleast as high a priority as correctness of function.

(See Appendix B, Section 4.3.2for more information on

PLC software considerations.)

5.1.8. Latched Outputs

A common practice for starting equipment is to send apulse to start the equipment, and "seal in" the pulse tokeep the equipment running. The advantage of a seal-incircuit is that when power is cycled off and then on, theequipment shuts down and stays shut down untilanother start pulse is received. Sealed-in circuits

eliminate the inadvertent re-start of motors, pumps, etc.when system power cycles.

Recommendation:

For latched outputs that start equipment, theprogrammer should not program latched outputs thatstay latched through power cycling. A holding circuitwith "seal-in" contacts, commonly done with relays,should be implemented in the PLC program.(See Appendix B, Section 4.3.2for more information on

PLC software considerations.)

5.1.9. "Queue Full/Empty" Indicators

Some PLCs make queue data structures available to theprogrammer. These queues can be either LIFO (Last InFirst Out) or FIFO (First In First Out) structures. Mostmanufacturers provide status bits for the queueoperation. Typically, the status bits are enable, full, andempty. The queues used may have full and emptyindicators. If so, the programmer should use theseindicators to ensure that the data being loaded orunloaded from the queue is not lost or invalid (i.e., theprogrammer should take appropriate actions if a full orempty status is determined).

Guideline:

PLCs with no queue full or empty indicators are notrecommended for use in safety shutdown applications.For software configurations in which a queue is used itis the PLC programmer's responsibility to test for thequeue status bits and take appropriate action.

(See Appendix A, Section 3.4.2 for a discussion ofcomplex functions.)

5.1.10. Error Handling

Errors can occur occasionally. For example, ifarithmetic is being done in a function block, divide-by-zero will cause an error condition to be asserted andthe function block to be terminated. If this errorcondition is not handled by the programmer, the actionof the program may be unexpected and lead to ahazardous condition.

Guideline:

The software configuration should test for errorconditions and take appropriate action.

NUREG/CR-6090 12


(See Appendix A, Section 3.4.2for a discussion ofcomplex functions.)

5.2. Configuration Testing

Typically, design and development of the hardwareand software will progress in parallel. After completionof the hardware configuration and field connections,the hardware portion of the safety system should beexercised without the safety system softwareconfiguration installed. The recommendation andguidelines for testing the hardware portion of the safetysystem are detailed below. Items 5.2.1 and 5.2.2 applyto testing of both the hardware and softwareconfiguration. The remaining items address testing andV&V issues associated with configuration of thesoftware. In these software testing items, it is assumedthat the hardware portions of the safety system havepassed all of their functional testing.

5.2.1. Test Plan

The components of the system, the subsystems, and thecomplete system need to be tested. These tests mayoccur at various sites and be performed by variouspeople. The key is not by whom or in what location thetest is completed, but that the test is well thought out,completed, documented and independently verified. Inorder to maximize the areas of the system that areexercised in the limited time available for testing, awell-thought-out plan should be developed beforetesting begins. The test documentation should providean auditor with an understanding of what was tested,why it was tested, and how much of the system wastested. ISA's manual, ISA RP55.1 provides acomprehensive discussion on testing processcomputers.

Recommendation:

A test plan should be written that clearly describes allsteps in the test, defines what constitutes success, anddetails how the test results will be documented.(See Appendix B, Section 4.4for more information on

testing considerations.)

5.2.2. Failure Documentation

Documenting failures and calculating statistics can beinvaluable. Keeping accurate historical records of thefailures can show trends in component failures. Thesetrends can help determine failure-prone areas in thesystem. By keeping complete records of all failures

that occur in the system's life, the system's expectedreliability can be calculated. This process of collectingstatistics and keeping records on failures starts duringtesting and continues for the life of the system.

Recommendation:

All failures and appropriate parameters (time ofoccurrence, time to repair, etc.) that occur duringtesting should be recorded. For each failure, the reasonfor the failure and corrective action taken should berecorded.

(SeeAppendix B, Section 4.6for more information onhardware and software maintenance.)

5.2.3. Software Verification andValidation

Software verification and validation (V&V) is anintegral part of the software life cycle and relates to thesafety life cycle. Proper implementation of averification and validation process can improve thequality of the software and the configuration'sadherence to the original system and safetyrequirements.

Recommendation:

There should be a formal independent verification andvalidation process for all of the PLC applicationsoftware.(See IEEE P-7-4.3.2 for a discussion of software

V&V.)

5.2.4. Software Fault Tree Analysis

SFTA is a process used to improve the safety of thesoftware by decomposing the code into root causes ofpostulated failures. SFTA is an extension of the morepopular FrA performed on electromechanical systemsthat includes the software components within the FTA.In SFTA, hazards are identified and decomposed intothe events leading to the hazard. The events can behardware failures, software failures, human errors, etc.The goal is to reduce the number of root causes. ThePLC configurable software then can be reorganized orre-configured to eliminate the software branches or thesoftware-based root causes in the fault tree. It isinconceivable that all the root causes, or even all thesoftware root causes will be eliminated. Mostprogrammers develop the software configuration fromthe point of view of what they want the software to do.

13 NUREG/CR-6090


SFTA looks at what the software shall not do. TheSFTA starts with the system fault tree, which isdifferent from the software requirements specificationand thus can expose errors in the softwarerequirements specification. By providing an alternateview of the software and starting from a differentspecification, the SFTA results in a greater confidencethat the software will mitigate a hazard. Reports byBowman et al., Leveson and Harvey 1983, andLeveson et al 1991 illustrate the software FTA processand examples of its use.

devices are connected in parallel, the first one to turnon will be excessively stressed. Also, the "ON"resistance may be different in each device, causing thecurrent division to be unequal. This may also causeexcessive stress in one of the devices. Connectingoutput devices in parallel to increase current capacitycauses an abnormally high rate of failures (Wilhelm1985). The proper design will use one switching devicewith the proper interface. If parallel output devices aredesired for a fail-safe design, then each output deviceshould be rated to properly handle the full load.

Guideline: Recommendation:

Perform a Software Fault Tree Analysis on the PLCconfigurable software as detailed in the papersmentioned above. The SFTA is a tool to help exposeerrors in the software configuration and the softwarerequirements. As such, the level of analysis willdepend on the complexity of the softwareconfiguration.

(See Leveson et a 1991 for more information on faulttree analysis.)

5.3. Installation

5.3.1. Installation Practice

Proper installation of the system is critical to reliableoperation. Improper installation can cause failures thatmay have severe consequences. Good installationtechniques will make maintaining the system easierand reduce the possibility of maintenance errors.

Guideline:

Verify that (1) correct hardware and softwareconfigurations are properly installed, (2) good industrypractice is being used in wiring, (3) the proper versionsof the software (i.e., operating system, translationsoftware, tools, software configuration, etc.) areinstalled, and (4) various pieces of the system areinstalled in the correct environmental conditions.

(See Appendix B, Section 4.5for more information on

installation concerns.)

5.3.2. Parallel Output Devices

Output devices should not be connected in parallel toincrease current carrying capacity. Output devicespecifications will not guarantee simultaneousswitching for identical devices. Thus, if two identical

No output devices should be connected in parallel toincrease current carrying capacity. Each output deviceshould be properly rated to handle the full loadexpected from the field device.



5.3.3. Inductive Voltage Spikes

An inductive DC load connected to an output moduleshould have a diode in parallel with the load or othermechanism to suppress the surge when the inductor isswitched off. This surge can create a voltage spike ifthere is no suppression mechanism. This spike maydamage the output module.

Recommendation:

An inductive DC load should have a surge suppressionmechanism installed. This mechanism may be suppliedin the output module by the manufacturer or may beinstalled as part of the field wiring.



5.3.4. Power Source Isolation

Computers are sensitive to power source variations.Voltage or current surges in the power source cancause damage to the PLC electronics.

Recommendation:

The PLC system should have its own isolated powersource and, if the system requires it, an uninterruptiblepower source (UPS).

NUREG/CR-6090 14


(See Appendix B, Section 4.5for more information oninstallation concerns.)

5.4. Maintenance

5.4.1. Technical Specification Update

With the introduction of a PLC into the system, somenew items may have to be included in the technicalspecifications for the plant. For example, the back-upbatteries will need to have surveillance performed fromtime to time, as will any air filters on the air intakes ofthe PLC cabinets.

Recommendation:

The technical specifications of the plant need to beupdated to include all applicable items from the PLCsystem.


maintenance concerns.)

5.4.2. Documentation of Failures

Tracking failures can help operators to forecast trendsin high-failure-rate components or identify softwareconfigurations with high failure rates. Tracking canhelp determine which hardware components should bekept on the shelf as spare parts. High failure rates on acertain part of the system can indicate a problem,which then may be investigated.

Guideline:

When a failure occurs the system should be thoroughlydiagnosed and all hardware problems found andrepaired. There should be in place and in force asystem for documenting all hardware failures, softwarefailures, software errors, and design errors. Thedocumentation should include when the failure or erroroccurred, What diagnostics were run, what thediagnostic discovered, the resolution, and what wasreplaced or changed.


maintenance concerns.)

5.4.3. PLC Module Replacement

Typically, maintenance of a PLC system is done byremoving and replacing modules. Some PLC systemsallow this to occur without removing power from themodule to be replaced, but some do not. Maintenance

procedures should clearly spell out what procedures areto be followed when a module is to be replaced.Further, some modules require customization prior toinstallation. If such is the case, those modules requiringcustomization should be clearly identified on themodule, in order that the proper customization is notforgotten when an installation is anticipated.

Most PLC vendors provide mechanisms that preventthe installation of an incorrect module in a slot. Onesuch mechanism is a slot key, which is customized forthe module to be installed in the slot, and thereforeprevents the installation of the wrong module. Anothermechanism is the "traffic cop"-software thatinterrogates a module after installation to see if it is thecorrect one and prints an error message if it is not. (Insuch systems plugging in the wrong module will notdamage the module but it will prevent correctoperation.)

Recommendation:

Mechanical, electrical or administrative controlsshould be in place so that when modules are changedout for maintenance, modules are not damaged and thecorrect module is properly configured and installed.

(See Appendix B, Section 4.6.1 for more information on

hardware maintenance concerns.)

5.4.4. Input/Output Forcing

"Forcing" is the action of putting a binary PLC input oroutput into a known state. In most PLC systems, a usercan force any of the 1/0 points. This operation iswidely used in debugging the program and verifyingproper operation of 1/0 points and connectedequipment. However, considerable care should beexercised when using this function. Forcing afterinstallation causes equipment actuation (valves toclose/open, motors to start/stop, etc.). Devices such assafety interlocks, motor hold-in contacts, and othersafety circuits can be bypassed or modified by forcedconditions, increasing the probability of a hazardoccurring. In addition, once an 1/0 point is forced, thePLC may not automatically return the 1/0 point tonormal operation. Most PLC systems remove all forced1/0 points once the programming terminal is switchedoff or disconnected from the PLC. The user shouldknow enough about the plant process, the PLC system,and the characteristics of the forcing command to useforcing properly. Further, in safety applications, theforcing commands should not be used without strictadministrative control.

15 NUREG/CR-6090


Recommendation: 5.5.2. On-Line Programming

There should be a means to control the use of the"forcing" function. Forced conditions should only beallowed under strict administrative control when thePLC system is providing. protection during plantoperation.

(See Appendix B, Section 4.6.2 for more information onsoftware maintenance concerns.)

5.5. Modifications

5.5.1. Modifications

Modifications to the hardware or software may berequested by engineering, operations, maintenance, thePLC manufacturer, and others. Modifications may beenhancements to the system or fixes to problems. Aformal procedure should be in place to receive problemreports, review them, suggest modifications to fix theproblem, and to implement and test the modificationwhen a modification is appropriate. Further, thisprocedure should include the assessment ofmodifications provided by the PLC vendor prior toinstallation. Any modification, especially a softwaremodification, has the potential to introduce hazardousstates into the system.

A modification should be checked for correct operationunder all plausible operational scenarios. Interactionswith other equipment should be checked for properoperation. And finally, after a modification is installed,it should be closely monitored and if problems arise, itshould be possible to revert to the old system while theproblems are considered.

Recommendation:

The utility should have a formal procedure to report,review, implement, and test all modifications.Unauthorized modifications should not be allowed.

(See Appendix B, Section 4. 7for more information onsoftware modifications.)

On-line programming allows the user to change thePLC program or data while the PLC is in run mode(operational). When using this feature, the user shouldbe very careful not to cause undesirable actions in thecontrol process. In safety-critical applications, tightcontrol should be maintained on all devices that allowon-line programming. The personnel making a changeshould fully understand the process, the equipmentbeing controlled, and the operation of the PLC system.

Recommendation:

There should be an administrative procedure to controlthe use of the on-line programming feature. On-lineprogramming should only be allowed under strictadministrative control when the PLC system isproviding protection during plant operation.

(See Appendix B, Section 4.7.2 for more information onsoftware modifications.)

NUREG/CR-6090 16

Appendix A:Programmable Logic

Controller Characteristics andSafety Considerations

J. PalomarR. Wyman

Manuscript Date: June 30, 1993

Contents

1: n ro u toIn..........................o.........uct..................on...............21...........2

2. PLC Definition........................................................................................................... 21

3. Intelligence................................................................................................................ 213.1. CPU ................................................................................................................ 223.2. Memory............................................................................................................ 223.3. Operation .......................................................................................................... 223.4. Functionality....................................................................................................... 22

3.4.1. Fundamental Functions ....................................................... ............................ 243.4.2. Complex Functions........................................................................................ 26

4. Input Structure............................................................................................................ 304.1. Field Input Devices ............................................................................................... 304.2. 110 Module Terminations ........................................................................................ 304.3. Signal Conditioning .............................................................................................. 304.4. Isolation............................................................................................................. 314.5. PLC Interface/Multiplex Electronics ............................................................................ 324.6. Indicators .......................................................................................................... 32

5. Output Structure.......................................................................................................... \325.1. PLC Interface/Multiplex Electronics ............................................................................ 325.2. Signal Latching ................................................................................................... 325.3. Isolation............................................................................................................ 325.4. Signal Conversion ................................................................................................ 325.5. 1/0 Module Terminations ........................................................................................ 345.6. Field Output Devices............................................................................................. 345.7. Indicators ........................................................ e.................................................. 34

6. Power Supply............................................................................................................. 34

7. Communications ........................................................................................................ 357.1. System Formats ................................................................................................... 35

7.1.1. Master-Slave............................................................................................... 357.1.2. Peer-to-Peer................................................................................................. 36

7.2. Components........................................................................................................ 367.2.1. Transmission Medium..................................................................................... 367.2.2. Interface Electronics....................................................................................... 367.2.3. Configuration .............................................................................................. 36

7.3. Error Handling.................................................................................................... 367.4. 110 Configurations................................................................................................ 37

7A.4.. Local........................................................................................................ 377A4.2. Distributed.................................................................................................. 37

7.5. Capacity............................................................................................................ 37

8. Peripheral Devices........................................................................................................ 378.1. Progranmming Terminals ......................................................................................... 37

8.1.1. Modes of Operation ....................................................................................... 388.1.2. Select Commands.......................................................................................... 38

8.2. Select Devices..................................................................................................... 399. Programming.............................................................................................................. 39

19

9.1. Boolean ......................................................................................................................................................... 399.2. Ladder Logic ................................................................................................................................................. 40

9.3. Sequential Function Charts ........................................................................................................................... 409.4. Comm on Source Languages ......................................................................................................................... 41

10. Special Features ..................................................................................................................................................... 41

11. Failures .................................................................................................................................................................. 4211.1. Stalling ........................................................................................................................................................ 4211.2. Instruction M is-Execution ........................................................................................................................... 4211.3. PLC M em ory .......................................................................... .................................................................... 4211.4. Interm ediate M em ory .................................................................................................................................. 4311.5. I/O Address ................................................................................................................................................. 4311.6. I/O M odule .................................................................................................................................................. 4311.7. Infant M ortality ............................................................................................................................................ 44

12. Redundancy ........................................................................................................................................................... 4412.1. PLC Processor ........................................................................................................................................... 4412.2. /O ............................................................................................................................................................... 4512.3. Comm unications ......................................................................................................................................... 46

13. Fault-Tolerant System s ......................................................................................................................................... 47

14. PLC Classifications ............................................................................................................................................... 48

Figures

Figure A-1. PLC Run-Tim e Operation ....................................................................................................................... 23Figure A-2a. On-Delay Tim er Operation ............................................................................................................... 25

Figure A-2b. Off-Delay Tim er Operation .............................................................................................................. 26

Figure A-3. On-D elay Retentive Tim er Operation ............................................................................................... 27

Figure A-4. PLC Input Structure ................................................................................................................................. 31

Figure A-5. Viso Test ............... ! ................................................................................................................................ 32

Figure A-6. PLC Output Structure .............................................................................................................................. 33

Figure A-7. Ladder Logic Program ............................................................................................................................. 40

Figure A-8. Exam ple Sequential Function Chart ................................................................................................... 41

Figure A-9. A Failure Detection Technique Used in Output Modules .................... I ............................................. 43

Figure A-10. Dual Processor with Single I/O ............................................................................................................ 45

Figure A-11. Triple Processor with Single 1/0 .................................................................................................... 46

Figure A-12. Dual Processor with D ual I/O ................................................................................................................ 47

Figure A-13. Triple Processor with Dual 1/0 ....................................................................................................... 49

Figure A-14. Triple Processor with Triple I/O ........................................................................................................ 50

20

Appendix A:Programmable Logic

Controller Characteristics andSafety Considerations

1. INTRODUCTION

Appendix A provides an overview of programmablelogic controller (PLC) characteristics. The intent is togive the reader some understanding of the mostpopular characteristics of programmable logiccontrollers. No attempt is made to discuss everycharacteristic available in the industry; however,characteristics that make the programmable logiccontroller more suitable for emergency shutdown thanother electrical/electronic based systems or improvereliability are described in more detail. In addition,characteristics that may provide an unsafe operatingenvironment are also commented on.

2. PLC DEFINITION

Since the advent of the microprocessor, digital systemshave been taking over more real-time control systemfunctions. Digital control systems have become anaccepted standard for control. Digital control systemscapture and utilize the power of the microprocessor.This power has been put to good use in control of alltypes of processes, from small research anddevelopment systems running a couple of motors tohuge control systems running oil refineries, steel mills,and power plants. Commercial computers such as theIBM PC, Macintosh, DEC computers, and HewlettPackard computers are general-purpose computers.Special-purpose computer systems have been designedto improve the performance, user interface, andoperation of various control schemes. Such designs areoften referred to as digital controllers, and they havebeen designed for specific applications such as motorcontrol, PH) control, and sequencing logic.

One such special purpose computer or digitalcontroller, originally designed to replace industrialrelay-based control systems, is the ProgrammableLogic Controller (PLC). The PLC has evolved into

more than a logic solver and with this has come analternate name of programmable controller, PC. Toeliminate the confusion between personnel computer,PC and programmable controller, PC, this paper willrefer to a programmable controller or a programmablelogic controller as a PLC. The major differencebetween a PC and a PLC is the programming language.The common programming languages for a PLC arerelay ladder programs, Boolean equations, andsequential function charts.

There are very few differences between a PLC andother digital control systems. NEMA ICS3-1978, PartICS3-304, defines a PLC in general terms that includecomputers and digital controllers of all types. For thepurposes of this paper, a more focused definition of thePLC is as follows:

A programmable logic controller is a digital operatingelectronic apparatus which uses a programmablememory for the internal storage of instruction forimplementing specific functions such as logic,sequencing, timing, counting, and arithmetic tocontrol, through digital or analog input/outputmodules, various type of machines or processes. Thedigital apparatus must offer at least one restrictive,higher level, programming language such as ladderlogic programming, Boolean programming, orsequentialfunction charts; must contain an operatingsystem that can execute its software in a deterministicmanner; and must interface primarily to sensors andactuating devices. The programming language mustoffer as a minimum relay coil and contact, timing,counting, and latch instructions.

3. INTELLIGENCE

Many features of the computer system may bedescribed in human terms, such as the CPU being the"brains" of the system. In this paper, the program and

Appendix A

the PLC operating system provide what will be calledmachine intelligence.

The machine intelligence of the PLC is derived frommicroprocessor-based electronics. At a minimum, aPLC system consists of a central processing unit(CPU), read-only memory (ROM), random accessmemory (RAM), programming terminal interfaceelectronics, and I/O interfacing electronics. The CPUhandles all activities of the PLC system. The CPUprovides a user programming environment, executesthe user program, analyzes incoming data, andresponds to the incoming data via control signals to theoutput modules. Every PLC offers basic relayfunctions, and most expand the functionality to cover awide variety of complex functions.

3.1. CPUAll PLCs contain at least one CPU, (typically oneelectronic printed circuit board) that executes userprogram instructions. It is the central unit that guidesall operation within the PLC. In more complexsystems, this unit will communicate with and controlthe operation of other subsystems within the PLC.Other subsystems may be arithmetic logic units,floating point processors or co-processors. However,the distinguishing feature of the CPU is that it hascentral control over the entire PLC system. Thesubsystems may contain microprocessors, but theircontrol is limited to the subsystem.

3.2. Memory

Two basic types of memory are available to the CPU-ROM and RAM. Typically, the operating system andprogramming language commands are stored in ROM,while the user program and the input/output data arestored in RAM. ROM memory cannot be changed bythe CPU, while RAM memory can be.

ROM memory is programmed at the time ofmanufacture, and the only way to change the ROMprogram is by replacing the ROM hardware. Othertypes of ROM exist which may be programmed aftermanufacture, called as programmable read-onlymemory or PROM. They are erasable by high voltage(25-50 Vdc) or ultraviolet light, and can be re-programmed after erasure. The aforementioned typesof ROM must be removed from the circuit in order tobe reprogrammed, but a newer type, called electricallyalterable read-only memory (EAROM), may be erasedand re-programmed while in the circuit.

RAM memory may be changed many times by theCPU. The CPU uses the RAM to store the constantlychanging input/output data, intermediate calculations,user programs, and various data that must changeduring the operation of the PLC. Two types of RAMare available, non-volatile and volatile. Non-volatilememory holds its memory values even if power isremoved. This is known as core memory and utilizesmagnetic fields to store bit states. Much more commonis volatile memory made of semiconductor material.This type of RAM requires battery back-up power tosustain memory through a power outage. This is a keymaintenance issue that should be addressed beforeselection of a PLC system. The PLC system shouldhave a means to indicate low battery power to theusers. Local indicators on the PLC are not sufficient.The battery low status should be reported to all userinterface devices as an alarm condition.

3.3. OperationThe PLC has various modes of operation. One mode,Run-Time, is of particular importance, and anunderstanding of this mode will aid in theunderstanding of the following sections. Run-Timespecifies the period of time in which the PLC executesthe user's program. It can be thought of as a sequentialprocess with five major steps. The first step is to scanall input modules, including any error checking ofaddresses/data and diagnostics. Next, an input imagetable in the PLC RAM is updated. Third, the CPUexecutes the user's logic program step by step, line byline. The data in the input image table is used asneeded in each step. Fourth, the output image table canbe updated. Finally, the PLC outputs the results to themodules. The execution of all five steps is called a scancycle. Note that the entire user program is executed inone scan cycle. The PLC repeats the scan cycle until itis stopped by the user or shut down in some other way.The five steps help visualize the flow of data, althoughin actual implementation, the execution of the stepsmay overlap in time. Figure A-1 outlines the Run-Timesteps.

3.4. FunctionalityThe PLC was designed to replace systems of industrialcontrol relays. The PLC increased the reliability,.increased the control information and data available tothe operators, and decreased the effort involved toretrofit a relay-based system. In this section, the PLCfunctions have been divided into fundamental andcomplex sets. The fundamental functions are those thatallow the PLC to replace the traditional industrial

NUREG/CR-6090 22

Appendix A

-------- w------ T -------------PLC __

Input Image Table

Current input module datastored in the PLC memory

User ProglramLadder logic, Boolean,

or SFC program.I I

_STEP 1PLC scans the input modules. PLCand I/0 modules run errorchecking.

9STEP 2PLC updates the inputimage table.

STEP 3PLC executes the userprogram.

STEP 4PLC updates the outputimage table.

Output Image Table I

Current output module datastored In the PLC memory. I

I--------------- I------1 ------- ISTEP 5PLC outputs results.PLC and I/0 modulesrun error checking.

Figure A-1. PLC Run-Time Operation.

23 23 NUREG/CR-6090

Appendix A

control relay applications. The complex functions haveevolved from more sophisticated control applicationsover the past years.

3.4.1. Fundamental Functions

The functions listed below are basic to all PLCsystems. These functions represent the original intentof the PLC, which was to replace industrial controlrelay circuits.

Standard Relay

The standard relay is very simple in construction andits function is easily implemented on a PLC. Thesignificant components of all relays are the coils andtheir contacts. The coil is energized and deenergized,opening and closing the relay contacts. The contactsare commonly called "normally open" or "normallyclosed," depending on their electrical operation. Thenormal position is the state of the contact when the coilis deenergized, also referred to as the shelf state (a termtaken from the perspective of seeing the relay in a storeon a shelf). The relay has no power and the relaycontact position at this time is called the normalposition.

Industrial control relay manufacturers refer to relaycontact configurations as Form "A," Form "B," orForm "C." Form "A" and Form "B" are normally openand normally closed, respectively. Form "C" containsnormally open and normally closed contacts in asingle-pole-double-throw configuration. A Form "C"relay has three connection points, one for the pole, oneto make a normally open contact and one to make anormally closed contact. Form "C" is not supplied as aPLC function, but is easily implemented using anormally open and normally closed contact referencedto one coil.

The standard relay performs logic and isolateselectrical circuits from each other. A control systemimplemented with relays has relays that are controlledby field input devices, relays that control field outputdevices, and relays that merely perform logic. Anequivalent system implemented with a PLC would usethe I/O modules to provide isolation and interface tothe field input and output devices. The relays usedpurely to perform logic would exist in software only.Thus, many of the relays that would be incorporated ina relay-based control circuit are physically eliminated,existing only within the PLC software. The PLCsoftware uses reference designations on the coils and

contacts to associate contacts with their respectivecoils.

The user programs relay coils and contacts into thePLC as needed by the control scheme. The relay coilsare controlled by other relay contacts or input modulecontacts, which in turn control more relay contacts ormodule outputs. It is important to understand that therelay contact states follow the state of the coil. Anormally open contact stays closed as long as the coilis energized. As soon as the coil is deenergized thecontact opens.

Latch

The latch relay holds its state until it is unlatched.Typically, a latch relay has two coils, one that"latches" the relay and one that unlatches it. Once thelatch coil is latched, it may be energized anddeenergized any number of times without affecting thestate of the contacts. It takes subsequent unlatching tochange the states of the contacts. For example, anormally open contact is closed when latched and willremain closed until the relay is unlatched.

Typically, the PLC contains two instructions toimplement the latch function, one instruction to latchand another to unlatch. The latch, unlatch andassociated contact instructions have a referencedesignation to indicate that they all act as one relay.

One-Shot

The one-shot relay changes the contact state for onescan cycle. Typically, two types of one-shots areprovided, leading-edge transition and trailing-edgetransition. A transition from deenergized to energizedis considered to be a leading-edge transition, whilegoing from energized to deenergized is a trailing-edgetransition. When the input coil receives the correcttransition, the contact transfers state for the remainderof the scan cycle. At the end of the scan cycle, the one-shot resets to its original state.

Timer/Counter

Two basic timer functions exist, "on-delay" and "off-delay." The on-delay timer has timed output contactsthat hold their states for a specified delay time after thetimer is activated, while the off-delay timer contactshold their states for a specified delay time after thetimer is deactivated. Figures 2a and 2b show the timingdiagrams for their respective timers. Both types of

NUREG/CR-6090 24

Appendix A

II IIII

II

1

Input Signal

Normally OpenInstantaneousContacts

0

1

0

I I I I I

1Normal ly OpenDelay Contacts

II I III

Delay ContactPeriod Transfer Normal State

I~~~0

Normal State

INormal ly ClosedDelay Contacts o

Figure A-2a. On-Delay Timer Operation.

timers have an input signal, instantaneous contacts, anddelay contacts. The contacts may be normally open ornormally closed for most PLC systems. Theinstantaneous contacts change state immediately uponenergization/deenergization of the timer. For anormally open contact, if the input signal is energized,the contact is closed. The instantaneous contacts maynot be provided by the manufacturer, but the contactsare easily implemented with a standard relay and oneof its contacts. The delay contacts depend on the typeof timer. The on-delay timer delays operation of thecontacts for a specified time after energization, and forthe off-delay timer, the delay comes after the timer isdeenergized. When the on-delay timer is energized, theinstantaneous contacts change states, and the internaltimer starts. After the elapsed delay time, the delaycontacts transfer. The delay contacts hold until thetimer is deenergized.

Counters simply count up or down. Energization of thecounter input initiates counting. Each counter has

normally open or normally closed contacts associatedwith it. The contact transfer occurs after completion ofthe count, which may be up to a preset value or downto zero. Depending on the manufacturer, counters areprovided to count scans or time. The current marketsupports time counters with resolutions as high as0.001 seconds. When using resolutions this high,careful attention must be paid to scan times. Forinstance, if the scan time is on the order of 0.1 secondsand control of an output is desired on the order of0.001 seconds, a problem exists-the controlled outputwill never respond in time because of the inherenttime-limiting nature of the PLC scan cycle.

Retentive timers are common. These timers react onceto their input condition, then they must be reset inorder to react again. Both timers and counters areavailable as retentive functions. For timers, the timedcontacts respond once after the initial delay and thenhold that state until a reset signal occurs. Figure A-3shows a timing diagram for a retentive timer.

25 NUREG/CR-6090

Appendix A

II II II

1

Input Signal

Normal ly OpenInstantaneousContacts

0

1

0

I I I I

1Normal ly OpenDe lay Contacts

I I III IDelay ContactPeriod Transfer Normal State

Pei o TransNormal State

0

Normally Closed 1Delay Contacts 0

Figure A-2b. Off-Delay Timer Operation.

Some key operational concerns about timers andcounters are worth noting. The reset conditionoverrides the time or control input. As long as the resetis active the timer or counter will be in the resetcondition, typically the shelf state for the outputcontacts. In addition, caution must be taken whenrestoring back-up copies of software that containtimers or counters. Some PLCs store the currenttimer/counter values when backing up, and restore thatvalue, while others do not store current values andinstead restore reset values. The user must make surethe restored values are the desired ones. One other keyoperational note is that when the PLC is in programmode, most PLC systems automatically reset the timersand counters, which may not be desirable.

3.4.2. Complex Functions

Data Manipulation

Move functions transfer data between areas of memory.These areas include, PLC RAM, 110 module RAM,hard-disk file, PLC CPU register, and 1/0 CPUregister. Each function transfers one element or groupof elements between any two memory areas. Someinstruction examples are:

MOVE Moves a single element from onememory location to another.

BLKMOVE Moves a group of elements of the sameformat from one memory location toanother.

TBLMOVE Moves one element of a group ofelements to a single element memorylocation.

SWAP Swaps two single elements.

NUREG/CR-6090 226

Appendix A

II

II

IIII1

Input Signal

Normal ly OpenInstantaneousContacts

Deenergized Deenergized0

1

0

I

I I I I

I I I I

Normal ly OpenDelay Contacts

I I

1Reset SignaII I

I

0

Figure A-3. On-Delay Retentive Timer Operation.

Shift functions manipulate data contained in tabularform. Tabular form data is stored in a block ofconsecutive memory locations. The data is shifted upor down. The input and output to a shift function aredesignated as source and destination, respectively. Thesource and destination are typically any memorylocation or 1/0 point. Shift-up outputs data from thehighest memory location to the destination, shifts alldata to the next highest memory location, and inputsdata from the source to the lowest memory location.Shift-down is the reverse. Data from the lowestmemory location is shifted to the destination, all data isshifted to the next lowest memory location, and sourcedata is input at the highest memory location. The shiftdirection, destination location, source location, tablestarting location, and table size are usually provided bythe programmer.

Search functions are exactly that. They search forspecific data over a specified range of memory

locations. The range could be specified as a file onhard-disk or a table in PLC RAM.

Queue functions are similar to shift functions, exceptthey operate on a particular area of CPU memorycalled the queue or stack. The common queue types areFIFO and LIFO, "first in, first out" and "last in, firstout," respectively. LIFO queues are sometimes called'ýpush down stacks." The queue has a maximumcapacity. Associated with the queue are twoinstructions: load and unload. In FIFO, a loadinstruction loads one data element on to the top of thequeue and unloads one data element from the bottom.For LIFO, the top element of the queue is loaded andunloaded. Most queues have indicators that monitorwhen the queue is empty or full. A conscious effortmust be made not to overflow the queue on PLCsystems with no queue full indicators. PLCs with noqueue full indicators are not recommended for use insafety shutdown applications. It is the programmer's

27 NUREG/CR-6090

Appendix A

responsibility to test for the queue overflow, as well asother error conditions, and take desirable actions.

Bit Manipulation

Manipulation and comparison of individual bits aresome of the most useful functions in a PLC system. Bitoperations may be performed on data words (typically16 bits) or tables of data words. Bit operations can bevery time-consuming. In order to keep the scan time toa minimum, the bit operations are divided into modesof execution. Three popular modes are incremental,continuous, and distributed. Incremental mode operateson one data word at a time. Continuous modeprocesses an entire table in one scan. Distributed modebreaks up the table into smaller sets and processes thedata over more than one scan. The list below specifiesthe most common functions:

" ORing

" Shift Left/Right

* ANDing

* Rotate Left/Right

" EXCLUSIVE ORing

* Comparison

* COMPLEMENTing.

ORing, ANDing, EXCLUSIVE ORing, andCOMPLEMENTing are standard Boolean logicoperations performed on two words or two tables bit bybit. Shift and rotate are standard computer shifts ondata words or tables. The difference between shift androtate lies in the control of the end bits. For shift, theend bits are input by the CPU and output to the CPU.For rotate, the end bits cycle around to each other.

Comparison examines any two words or two tables fora bit mismatch. Two status contacts are typicallyprovided. One status contact indicates that acomparison is in progress and the other indicates amismatch occurred. When a mismatch is found, thecomparison function specifies the position of themismatch. The position of the mismatch is usuallylogged into an error file and/or displayed on anoperator's screen. Comparison allows diagnostics ofthe field devices. The I/O modules communicate to thePLC CPU with 8- or 16-bit words. For discrete 1/0,each bit of the word represents an I/O point. At variousstages of the process (especially at start-up), thesediscrete I/O words or tables may be compared topredetermined words or tables to verify proper

operation of the field devices. If a mismatch is detectedthe PLC can correct for the problem or shut down theprocess.

Math Functions

The four basic math functions of addition, subtraction,multiplication, and division are usually supplied.Additional functions may be modulo-division,remainder, square root, and negate. Also furnished arethe standard equality operators of equal to, greaterthan, less than, greater than or equal to, less than orequal to, and not equal to. Typically, math functionsrequire specific registers to be used for operands andresults. This requirement, along with the mechanics ofsetting up the math functions, are typicallycumbersome.

Type Conversion

Most of the time, the PLC data is displayed in decimalformat, but the PLC may store the data in a number ofdifferent formats. Any computer data format may beused. Some examples are BCD, ASCII, unsigneddecimal, integer, floating-point, double, etc. Due tothis, most PLCs provide type conversion functions thatconvert the data from one format to another.

Control Functions

"Control functions" covers an ever-evolving area ofcontrol algorithms. Common in virtually every PLC isthe popular PID process control algorithm and itsassociated variations of ratio, cascade, adaptive, andfeed-forward control. Another popular control functionis the sequencer, which controls a set of digital outputsby the use of data tables. Each column of the data tablerepresents the states for one digital output and eachrow of the data table is one sequence. Via the userprogram, the sequencer progressively steps througheach row of the table at various scan times. Thus, thedigital outputs are sequenced on and off. The programdictates the time interval between steps of thesequence, while the sequencer contains the controlinformation for each sequence.

Diverse control functions exist from variousmanufacturers. Implementation of control functionsmay be in a neatly packaged I/O module, or a PLCsoftware package using analog I/O modules. Thisfunctionality is specific to user needs. Wherever a largecustomer base for a specific control application exists,the PLC manufacturers are sure to respond. Some PLC

NUREG/CR-6090 28

Appendix A

control functions provided by various manufacturersare listed below:

" Servo Positioning (with encoder)" Plastic Mold Injection Control

• Stepper Positioning• Real Time Clock

* Linear Positioning

* Sheet Metal Press Clutch/Brake Control

* Axis Positioning.

Subroutines

Standard computer subroutine capabilities are offeredon most of the larger PLCs. The instructions includejump-to-subroutine and jump-to-label. Jump-to-subroutine allows repetitive calling of subroutines inone scan. Excessive scan times may occur when usingsubroutines, especially when using repetitive calls tosubroutines. Jump-to-label jumps to another location inthe program for that particular scan.

Special Languages

In an effort to insert more versatility into the PLCsystem, various manufacturers are offering BASICprogramming modules. These modules allow users toprogram their particular applications using themanufacturer's proprietary form of BASIC. TheBASIC module runs BASIC programs independentlyof the PLC processor. The necessary input data andresultant output data is the only information passedbetween the PLC processor and the BASIC module.The PLC processor scans the BASIC module duringnormal input and output scan times.

Another approach to expanding versatility is providingthe PLC system with communications to largemainframe computers. One manufacturer has built aPLC system to the VME bus standard. This systemuses the VME standard as the backplane for all PLCsand I/O modules; thus any other VME module mayinterface to the PLC system. VME is an open-architecture, industry standard, modularinstrumentation system. Various manufacturersproduce instrumentation and computer modulescompatible to VME. VME module types range fromDEC VAXstation to IBM PCs to discrete inputmodules.

When common programming languages such asBASIC, Pascal, or C are used in the PLC system, the

software must be developed and maintained under therequirements of any other microprocessor-basedsystem used in emergency shutdown applications. Arigorous development, review, testing, andmaintenance scheme such as that outlined in IEC-880is required and must be followed.

Report Generation

Most PLC systems produce helpful reports. The ladderlogic program, Boolean program, or sequentialfunction chart may be printed as seen on theprogramming terminal screen. Cross referencesbetween coils and their associated contacts may begenerated. This is very handy for troubleshooting andcheck-out. Annotation may be added to programs asdesired. Other possible reports are I/O module status,program directory, memory mapping locations, andmemory usage.

Peripherals

While one manufacturer may provide only a fewapplication-specific peripheral devices, the PLCindustry as a whole has an abundant number of thesedevices. They allow communications to other computersystems, provide a means of program and data storage,furnish hard-copy outputs, aid in debugging andtroubleshooting, and improve the users' and operators'environment.

Most manufacturers offer I/O modules or internal PLChardware that links the PLC system to PCs, largemainframe computers, printers, other PLCs, special-purpose interface boxes, networks, etc. A short list ofcommunication protocols offered in PLCs is:

" RS-232 serial link" GPIB-488

* RS-422 serial link• RS-485 multidrop" RS-423 serial link* MAP 802.4• RS-449" Ethernet

" Manufacturer's Proprietary Networks.

This versatility in communications opens up a widearray of functionality and complexity for a PLCsystem. Tape recorders, floppy disks, and high-densitycomputer-grade tape cartridge recorders may connect

29 NUREG/CR-6090

Appendix A

to PLC systems. The entire selection of printer types,from dot matrix to graphic printers, are available.Simulation panels, simulation modules, and evencomputer-based simulators are provided to check outPLC systems. Another very popular peripheral is thecolor-graphic terminal. Color graphics enhance theoperator's environment by color-coding the processfunctionality and giving graphical representation to thetedious lines of programming code. The user'senvironment has also been aided with portability. Boththe programmers and maintenance personnel haveaccess to hand-held or portable terminals to assist introuble-shooting, calibrating, configuring, andprogramming the PLC system.

Self-Diagnostics

As the electronic industry improves upon the size andspeed of microprocessors, the PLC industry has addedmore and more functionality to all parts of the PLCsystem. Self-diagnostics of the PLC hardware is acritical area that has seen much improvement over thepast years. PLC manufacturers have added diagnosticsof the hardware into the PLC hardware, the PLCsoftware, and the 1/0 modules. These diagnosticpackages verify such things as communications,runtime status, process status, PLCstatus/hardware/memory, and 1/0 modulestatus/hardware/memory. Included in the diagnosticpackages are reporting functions and fault logging.Some systems take corrective action when a fault isdetected.

4. INPUT STRUCTURE

This section describes the structure of the standarddiscrete and analog input modules. The modules notaddressed are the specialized communication modules,such as RS-232 communication modules, master-slavenetwork modules, or any other special module notdirectly connected to a field device.

Input modules are either discrete or analog. Typicaldiscrete inputs are contacts, limit switches,pushbuttons, and pressure/flow/temperature switches.Analog inputs cover a wide range of applications andfunctionality. Some typical devices arepressure/flow/temperature transducers, motor controlsignals, vibration transducer, strain gage, load cell, andvarious other transducers producing electrical outputs.The input module receives signals from the field input

devices, conditions those signals, and isolates themfrom the PLC processor. The standard PLC inputstructure consists of six basic blocks, as shown inFigure A-4. Each will be described in detail.

4.1. Field Input Devices

The field input devices act as the "eyes and ears" of thePLC system. They provide the conversion fromphysical processes to control signals. For a PLCsystem, the control signals are electrical. Electricalsignals appear in many voltage levels and signalwaveforms.

4.2. I/O Module Terminations

1/0 module terminations provide the interconnectionbetween the field input devices and the PLC system.These terminations come in many designs andconfigurations. Some are fixed to the module, somecan be quickly disconnected, and others are fixed to thesupport structure of the I/O module. By allowing theterminations to be quickly disconnected or fixing themto the support structure, the 1/0 modules can beremoved and replaced without rewiring. This positiveattribute is highly recommended for a PLC systemused in emergency shutdown systems. All terminationsare typically locked down in some way, such as screwtermination blocks. In addition, the wire ends may beterminated with lugs'to ensure a positive tight contactthat will not loosen over time.

4.3. Signal Conditioning

Signal conditioning varies greatly depending on themanufacturer, the system architecture, and the type ofsignal conversion required. Discrete input conversionis relatively simple, while analog input conversions aremore complex. Some common types of conditioningcircuits are rectifiers, resistors,resistor/capacitor/inductor networks, and analogconversion. Rectifiers convert incoming AC signals tothe desired processor levels. Resistor networks provideDC level attenuation. Resistor/capacitor/inductornetworks remove unwanted noise spikes and reducefalse input triggering due to field device contactbounce. Analog conversion comes in two forms,counters or AMD converters. Counters transform pulsetrain waveforms into a binary number representing thenumber of pulses per unit time. A/D converters areused on varying DC level signals. They convert the DClevel to a binary representation of the level.

NIJREG/CR-6090 30

Appendix A

Field Input DevicesConversion of Process data ancivariables to electronic signals,

Input ModuleElectronics I/0 Module Terminations

PLC System connectionsof field devices.

Signal Conditioning

Rectifier ResistoRLC Network A/D

Isolation

Opto-IsoaIion TransformerJReed Relays

Interface/Multiplex4

Indicators

Provides high-speed image ofstatus of all input points.

LED Neon LampIncandescent Lamp

€PLC Processor

Central

Controller

of

LC

System

-------- L----------I---------------------------

PLC ProcessorCentral Controller of

.LC System

Figure A-4. PLC Input Structure.

4.4. Isolation

Isolation circuits mechanically and electrically isolatethe field device signals from the PLC processorsignals. Isolation limits the possibility of noise andvoltage spikes damaging the sensitive processorelectronics. Three isolation techniques are employed,the most common of which is opto-isolation. Beforethe advent of opto-isolation, transformers were themost common device for isolation, and are still used ina limited number of designs. Reed relays provide athird technique for isolation. A major drawback to reedrelays is the limited mechanical life. In the best reed

relays the contacts wear out within tens of thousands ofcycles. Thus, reed relays are not recommended inintense cyclic operations.

For opto-electronic devices a common isolation testmeasures the isolation surge voltage, Viso. Viso is ameasure of the internal dielectric breakdown rating ofthe opto-electronic device, not necessarily the I/Omodule. This voltage is placed across the device asdepicted in Figure A-5 below. A typical semiconductormanufacturer's published Viso for opto-electricisolation is about 1500 Vdc for 60 seconds and 1500Vac, 47 to 70 Hz, for 60 seconds.

31 NUREG/CR-6090

Appendix A

Figure A-5. Viso Test.

4.5. PLC Interface/MultiplexElectronics

This block gathers all incoming conditioned fielddevice signals, and transmits them to the processor asrequested. Control signals are produced by this unitand the PLC processor to coordinate the transfer ofdata. These signals may include clock, reset, enable,module address, handshaking, error-handling signals ordata. Some manufacturers provide watchdog timers inthis part of the I/O module. The watchdog timer mustbe reset by the PLC processor. Thus, if the processordoes not communicate to the I/O within a specifiedtime period, the watchdog timer expires and the I/Omodule de-energizes all outputs.

4.6. Indicators

Indicators assist the user in troubleshooting the systemand aid in verifying the integrity of the field wiring, themodule operation, and the module status. LEDs, neonlamps, and incandescent lamps are all used asindicators. The indicator location varies bymanufacturer and I/O module type. It may be locatedand powered on the field device side, the PLC logicside, or both. The field device side of an YO module iscomposed of all the electronics from the terminationpoint to the input of the isolation electronics. The PLClogic side contains all the electronics from the outputof the isolation electronics to the I/O module to PLCinterface electronics. The best configuration hasindicators on both sides of the electronics. As aminimum, an indicator should be provided on the fielddevice side.

5. OUTPUT STRUCTURE

Section 5 describes the standard discrete and analogoutput modules. The modules not addressed arespecialized communication modules (RS-232communication modules, master-slave networkmodules, etc.), co-processor modules, or any other

special-function module not directly connected to aprocess control element.

The format of the discussion below is analogous to thatof Section 4, Input Structure. Output modules areeither discrete or analog. Typically, discrete outputscontrol relay coils, valve solenoids, motor starters,panel indicators, and alarms. Analog outputs cover awide range of applications and functionality. Sometypical devices controlled arepressure/flow/temperature valves, motor controlsignals, analog meter and various other applicationsneeding electrical signals. The output module receivessignals from the PLC processor, converts and isolatesthose signals, and controls the field output devices. Thestandard PLC output structure consist of seven basicblocks as shown in Figure A-6. Each will be describedin detail.

5.1. PLC Interface/MultiplexElectronics

The PLC interface/multiplex electronics gathers thePLC processor signals, decodes the address, and passesthem to the appropriate output destination point. Manycontrol signals must be provided by the PLC processorto enable this block to function correctly. The signalsneeded vary depending on the manufacturer'shardware/software design, but some typical signals areclock pulses, reset, enable signals, addressing data, anderror handling data. Also, the interface/multiplexelectronics sends reply and status data back to the PLCprocessor.

5.2. Signal Latching

The signal latching circuitry receives data from theinterface/multiplex electronics. This circuitry containselectronic latches such as flip-flops to hold the latestdata received. The data is held until the next update ofoutput data. The PLC processor ensures that the latchblock is updated within a specified time period.

5.3. Isolation

The isolation circuitry for output modules is identicalin design to the input module isolation circuits.

5.4. Signal Conversion

The signal conversion circuitry converts the latchedsignals to the proper state acceptable to the field outputdevice. Remember, the signal conversion circuitry ison the field side of the isolation circuitry. Thus, the

N /REGICR-6090 32

Appendix A

PLC Processor

Central Controller of PLC System

-- -------------------Output Module

ElectronicsInterfac e/Muftiplex

Provides high speed image ofstatus for all output points.

Signal Latching

Hol ds image for all output points.

Isolation

Opto-Isolation TransformerReed Relays

I

Signal Conversion Indicators

ITriac Reed RelayTransistor D/A I Function: Blown Fuse & Status

Types: LED, Neon, Incandescent II A

PLC System connections toI10 Module Terminations I

PLC System connections to

field devices.

Field Output Devices

I

Conversion of electronic signalsto process control. I

Figure A-6. PLC Output Structure.

33 33 NUREGICR-6090

Appendix A

power for the signal conversion circuitry must comefrom the field side. This assures isolation of thesensitive PLC and output module electronics fromnoisy field devices. The signal conversion circuitrycontains a power switch, typically in one of four forms:triac, reed relay, transistor, or digital-to-analogconverters. It is a good idea to have a circuit protectorconnected in series with one of the power switches.The best designs have circuit protectors, such as fuses,in series with each output point.

5.5. I1/0 Module TerminationsThe output module terminations are identical to theinput module terminations. Typically, the terminationsare locked down in some way, such as screwtermination blocks. In addition, the wire ends may beterminated with lugs to assure, a positive, tight contactthat will not loosen over time. Another positiveattribute is the ability to remove and replace the 1/0module without rewiring. Many manufactures aremaking this capability possible by fixing the moduleterminations to the rack instead of the 110 module.

5.6. Field Output Devices

The field output devices provide the muscle to controlthe process, and the visual and audio information thatexpresses the process state. These devices convert thePLC control signals into process changes or status.Process changes are accomplished through control ofvalves, motors, relays, etc. Process status is presentedthrough graphical displays, horns, lights, and otherdevices.

5.7. Indicators

As in the input module circuits, indicators are providedto aid the user in troubleshooting. The output moduleindicators may be configured in the same manner asthe input modules; indicator powered from field side ofisolation. circuitry; indicator powered from PLCprocessor side of isolation circuitry; or both. The bestconfiguration would have indicators on both sides ofthe electronics. Some output modules have anadditional indicator to detect a blown fuse. The fuse islocated on the field side of the isolation circuitry andthe indicator connects in parallel to the fuse, so whenthe fuse blows the indicator lights up.

6. POWER SUPPLYThe power supplies considered are all sources of powernecessary to properly operate the PLC system. The first

and largest is the signal conversion electronics requiredto convert 120 Vac or 240 Vac into the low-voltageDC power necessary for operation of the processor and110 modules.

The power supplies may be located on each module(processor or 110), contained in the mounting rack, orthe processor module may supply power to the 1/0modules. The most common configuration of thepower supply is not the most reliable, but definitely themost economical. Most manufacturers design themounting rack such that each rack has one powersupply, making this one power supply a single-pointfailure. If the power supply malfunctions on a one-rackPLC configuration, it takes the whole PLC systemdown.

Both linear and switching power supplies are used inPLC power supply designs. Linear power supplies usetransformers, rectifiers, and various filtering anddetection circuits to transform high-voltage AC powerinto low-level DC power. The switching power supplyis a newer design that is physically smaller and has ahigher signal conversion efficiency. However, theswitching power supply responds more slowly toelectrical transients and intrinsically produces morenoise, which shows up as low-voltage ripple on the DCoutput lines and in EMI.

Some important features that should be designed intoboth types of power supplies are input filters, outputfilters, short circuit and overload protection, over-voltage and reverse-voltage protection, and incomingline monitoring. Input filters reduce incoming electricaltransients, while output filters stabilize the powersupply's low-voltage DC output and reduce unwantednoise. Short-circuit-overload circuits protect the powersupply from destroying itself during abnormal currentconditions. Likewise, over-voltage and reverse-voltageprotection circuits protect against abnormal voltageconditions. Incoming line monitoring is a highlyvaluable circuit, but not as common as the protectioncircuits previously mentioned. By monitoring theincoming line voltage and frequency, the power supplycan detect power outages and give warning to the PLCprocessor, allowing the processor to shut down thesystem in an orderly fashion. During restoration ofpower, the PLC system can then start up and continuenormal operations.

Another common power source for a PLC system isbatteries. Batteries are used to back up volatile RAMmemory or the real-time clock system. Manufacturersuse primary and secondary battery systems. Primary

NEJREG/CR-6090 334

Appendix A

batteries cannot be charged, while secondary batteriesare rechargeable. The PLC system should be capable ofproducing an alarm for low-battery status locally andremotely to users of the system. It is important to notethat remote alarm capability is essential. Often, thePLC system is locked behind cabinet doors and theusers rarely see the local displays. A low-battery statusat a remote terminal can reduce the probability of oneinexpensive battery shutting down the entire plant.

Primary battery types include carbon-zinc, alkaline,and lithium. All need replacement about once a year.The carbon-zinc family is rarely used in current PLCdesign because alkaline and lithium batteries offersignificant advantages. Alkaline batteries offer a lowercost and extended life over carbon-zinc types. Lithiumis the best family of batteries, offering three to tentimes the energy density, and twice the shelf-storagelife of other battery types. The disadvantages of lithiumare high cost and explosive hazard-lithium reactsviolently with as little as 100 parts per million of water.For this reason, lithium batteries are hermeticallysealed and must be transported under Department ofTransportation regulations (DOT-E 7052).

Lead-acid and nickel-cadmium are secondary batterytypes. This category of battery requires a rechargingcircuit, which makes secondary battery circuits morecomplex than primary battery circuits. Theirreplacement period is much longer than primarybattery types and depends on battery usage. Lead-acidbatteries are big and bulky. Most have gelledelectrolyte packaged in a plastic case. Lead-acidbatteries do not explode. At worst, the batteryoverheats, melts the plastic case, and corrodes anysurrounding metal and/or electronics. Nickel-cadmiumbatteries provide the same characteristics as the lead-acid type, but in a smaller package. They are availablein standard metal-cased AA and D sizes. Nickel-cadmium battery systems are used in the majority ofsecondary PLC battery systems.

7. COMMUNICATIONS

As PLCs grew, the requirement to communicate withother PLCs and intelligent external devices, such ascomputers, color graphic terminals, and othermicroprocessor based devices spawned the applicationof a vast assortment of communication networks toPLC systems. A comprehensive discussion of thedesign trade-offs of communication networks isbeyond the scope of this paper. Some of the mainconcepts and components of different communication

systems used in PLC systems will be covered below, aswell as a few drawbacks and advantages.

A PLC processor-to-processor network is a high-speeddata link designed for passing information between thePLC processor and other devices connected to thenetwork. The information may be in the form of data,control signals, addresses, system status, or individualdevice status. Most PLC systems use communicationrates of about 57 kilobaud, which is sufficient tosupport most of the process control applications.Manufacturers are pushing the upper bound of thecommunication rate to 2 megabaud. These highcommunication rates prove beneficial in movingimportant data to various components of a safetyshutdown system applied to power stations, refineries,steel mills, and the like.

Fundamental differences exist between two networksin a PLC system. One network, called the controlnetwork, transfers all information required from onePLC processor to all its mates (I/O, other processors,and other types of modules) within a single processorscan. The second network, called the system network,gives up the ability to transfer all data within oneprocessor scan and may not need to meet real-timerequirements. Either network may use the componentsand routines described below.

7.1. System Formats

Two basic system formats are used in PLC controlnetworks, master-slave and peer-to-peer. Mostmanufacturers use a proprietary protocol on the controlnetwork. PLC system and processor-to-processornetworks typically conform to available protocolstandards and may use master-slave, peer-to-peer, orother system formats.

7.1.1. Master--Slave

In the master-slave arrangement an intelligent devicemanages all network communications between allother devices on the network, known as slaves. Allslaves communicate to the master and only the master;no slave-to-slave communications are possible. For onenetworked device to communicate with another, itmust transmit its message to the master, who in turntransmits the message to the appropriate slave, amethod that gives the master device total control overall communications. A major disadvantage is that thecommunications is totally dependent on the masterdevice. Thus, a failed master device is a single-pointfailure that takes down all communications. Some

35 NUREG/CR-6090

Appendix A

manufactures offer a second back-up master to operatethe network in case the primary master fails. Themaster device may be a computer or a faster/largerPLC processor. A single point of failure still exists inthe switching mechanism, which can be composed ofhardware or software.

7.1.2. Peer-to-Peer

Each device in a peer-to-peer network has thecapability to directly communicate with any otherdevice on the network. Any number of devices mayfail and the network should continue to function. Aslong as two devices remain on the network,communication is possible. This control scheme isharder to implement because issues such as whichdevice controls the network, how long a device maycontrol the network, and the type of information passedon the network must be worked out. This scheme ofcommunications is often referred to as baton or tokenpassing, since control of the network is passed (like abaton passed in athletic track events) from device todevice.

7.2. Components

The various components of a communications networkare briefly discussed below. Any communicationnetwork used with computers can be used with a PLCsystem. The components mentioned below are the mostcommon used in PLC systems.

7.2.1. Transmission Medium

The transmission medium is the physical conductorused to convey information between various locations.Some common media are twisted shielded pair,coaxial, triaxial, and twinaxial wire/cable. The controlnetwork also uses a backplane, which is a short-lengthtransmission medium fabricated by printed circuitboard and/or wire-wrapping techniques. In specialapplications, telephone, radio wave, or evenmicrowave is used as the transmission medium.Recently, manufacturers are supplying fiber-opticcommunications. Fiber-optic communications offerlarge bandwidths, immunity to EMI, and completeelectrical isolation. Some disadvantages are the highcost and fragile nature of the cables and connectors.

7.2.2. Interface Electronics

Most communications networks contain a networkadapter module or modem to access the data from thenetwork and pass it on to the PLC processor. The

modem handles handshaking, error checking, media

use management, and network protocol.

7.2.3. Configuration

Many configurations are available. The daisy-chainconfigurations tie the network devices together one byone, so each device has two connecting neighbors,except the end devices, which only have one neighbor.This configuration is similar to a string of Christmastree lights, where each light represents one networkdevice. By connecting the two end devices of a daisy-chain arrangement a loop configuration is created.Multidrop systems are similar to daisy-chainarrangements except that at every device a signalsplitter is used. The splitters allow all devices on thenetwork to receive all messages transmitted on thetransmission medium. Another configuration, sparselyapplied in the PLC industry, is the Star configuration.One device is a central point to which all other devicesare wired, like the spokes in a wheel. Starconfigurations are easily adapted to master-slaveformats. Any of the mentioned configurations may beused for the control network, the system, or processor-to-processor network.

7.3. Error Handling

A communication system without error handling isextremely susceptible to the transferal of erroneousdata, which most likely will lead to incorrect control ofthe process. Error-handling algorithms have beendeveloped to correct for this. In the control andprocessor-to-processor network, the error-handlingroutines are designed into the network by themanufacturer. For the system network, the user canusually select the error-handling routines desired. Twolevels of error-handling exist, error detection and errorcorrection. The error-handling routines common toPLC systems are discussed below.

All of the popular routines used in computer systemsare used in PLC systems. Parity checks, often calledvertical redundancy checking (VRC), longitudinalredundancy checking (LRC), and cyclic redundancychecking (CRC) are used for error detection, whileforward error correction (FEC) and automatic repeatrequest (ARQ) are used for error correction.

The control network typically uses CRC with ARQ.CRC is the more complex algorithm and yields thehighest error-detection rate of the three'algorithms.Typically, ARQ is used with three re-transmissions.The sender will re-transmit upon receiving a negative

NUREG/CR-6090 36

Appendix A

acknowledge or not receiving a acknowledge after aspecified period of time. Typically, the senderretransmits three times before shutting down thecommunication link.

The system and processor-to-processor network error-handling routines use any combination of the aboveerror detection and correction routines. A few PLCsystems allow the user to program the desired errordetection in the system network. The user selects noerror detection, VRC, LRC, or CRC, and the PLCsystem usually adds ARQ error correction. Again, mostimplementations of the system network use ARQ errorcorrection with three re-transmissions.

One reason ARQ error correction is more commonthan FEC error correction is the substantial overheadburden of FEC. FEC requires nearly one overhead bitper transmitted bit, which puts an extreme burden onthe communication bandwidth.

7.4. 1/0 ConfigurationsThe 1/0 configuration plays an important role in designof the communication network and choice of errorhandling routines. Two configurations are explainedbelow.

7.4.1. Local

Local refers to the physical location of the PLCprocessor in relation to other modules. In addition tostandard I/O modules, the other modules may be co-processors or even other PLC processor modules.Modules installed within 75-100 feet of the PLCprocessor, determined by cable length, would beconsidered local configurations.

7.4.2. Distributed

Distributed or remote I/O configurations are PLCsystems where two or more PLC systems are linkedtogether to form a larger system. The total cable lengthfor some distributed PLC systems can be as long as20,000 feet. This is extremely long for a cable run, butlonger lengths can be obtained through telephone lines,radio waves, or microwaves. Another distinguishingfeature of the distributed system is that some sort ofsystem communications exist to allow data transferbetween PLC systems. Typically, a specific module ineach PLC system directs all the systemcommunications, including transmission to and fromPLC systems, error handling, additionalcommunications overhead, and communications with

its superior local PLC processor. This frees the localPLC processor to manage its local 1/0 modules.

7.5. Capacity

The amount of data that a master-slave or peer-to-peerformat can transmit depends on the design of thesystem. A communication system transmits messagesthat consist of data and overhead. Overhead refers tothe bits required to accomplish such things as errordetection, error correction, and message decoding.Data is the remainder of the message; the actual datathe receiver needs to accomplish its task. Data istypically transmitted in blocks of words. A wordconsist of 8, 16, or 32 bits, and a block contains manywords.

The data capacity of a communication system dependson such constraints as modem design, communicationprotocol, error-handling algorithms, and processordata-handling capabilities. For this reason, the rate ofdata words (words to be used by the receiver of themessage stripping away all the overhead required tosend the signal) transmitted, not bandwidth, is a mostimportant specification of the communication network.

8. PERIPHERAL DEVICES

Peripherals aid in programming, storing data, printing,emulation, simulation, or other functions the user mayneed or want. In addition to PLC manufacturers, anumber of third-party vendors develop peripherals.

8.1. Programming Terminals

The single most important peripheral is theprogramming terminal. The programming terminalaccepts the program commands of the user, convertsthem into machine-readable code for the PLCprocessor, and allocates the machine code into theappropriate memory locations within the PLCprocessor.

The most common programming terminal in the PLCindustry is a form of the video display terminal (VDT).Most PLC programs are developed on VDTs. Recently,smaller programming devices have been developed.This new group of programming terminals are hand-held and use liquid crystal displays. The hand-heldterminals compact size makes them very useful in thefield.

The PROM programmer loads PLC programs intoPROM devices. After programming the user inserts the

37 NUREG/CR-6090

Appendix A

PROM device into the appropriate PLC circuit boardsocket. PROMs eliminate reprogramming by the casualuser. Once the program is locked into PROM, a newPROM device must be physically inserted to changethe user's program. This level of program control andsafety may be desirable in safety shutdownapplications.

8.1.1. Modes of Operation

As in all computer systems, various modes of operationexist in the programming terminal. The two mostcommon modes are on-line and off-line. On-line andoff-line refer to the mode into which the PLC processoris placed by the programming terminal. Other modes ofoperation may be supervisory, executive, or monitor.These modes limit the user's access to the PLC system.For example, supervisory mode may only allowconfiguration of the 1/0 modules, and monitor modemay only allow viewing of the program flow and 1/0states.

On-line programming allows the user to add, change,or delete the PLC program or data while the PLC is inrun-time. The user must be very careful not to causeundesirable actions in the control process. Mostterminals let the user monitor the new programchanges before downloading them to the PLCprocessor. This way the user can monitor the changesuntil he or she is sure the correct process control willresult. In safety-critical applications, tight control mustbe maintained on all devices that allow on-lineprogramming.

No on-line programming changes should be made afterstart-up unless the on-line mode is deemed absolutelynecessary, and then only with the appropriate writtenapprovals of the change and use of the process. Thepersonnel making the change must fully understand theprocess, the equipment being controlled, and theoperation of the PLC system. The change should bechecked for accuracy and all possible process controlscenarios should be exhaustively thought through.

Documenting the change beforehand aids in thinkingthrough the change at the different development levels.The development levels include process controlspecifications, piping and instrument diagrams, ladderlogic drawings, and the ladder logic program listings.By going through the thought process potentiallydangerous changes may be caught before actualimplementation. Although this is a very precariousmode, it offers great flexibility when troubleshootingthe system.

Off-line is the more common programming mode. Theuser keys in the program to the programming terminalwith no effect to the PLC processor. After the programis written the user may download the program into thePLC processor. While in the off-line mode, theprogramming terminal will cause the PLC processor tostop scanning and de-energize all outputs beforedownloading.

Once a program is running on a PLC system, care mustbe taken when switching to off-line mode. Whenplaced off-line, many PLC processors reset the elapsedtime of counters and timers. In addition, the outputsreturn to the deenergized state. If some of thecontrolled equipment was in an intermediate state, itmay malfunction or be damaged when going off-line.Initialization and shutdown routines may be helpful.These routines place the PLC outputs in apredetermined safe state during start-up and beforeshutdown, respectively.

8.1.2. Select Commands

A number of commands are provided by eachmanufacturer. Some are necessary to program the PLCwhile others add user conveniences in each of thestages of development, debugging, and operation.Detailed discussions on every possible command arebeyond the scope of this paper, but one command is ofparticular importance because it may effect real-timecontrol of the output modules.

The "Forcing" commands hold an input or output at adesired state. These commands are typically FORCEON/FORCE OFF or ENABLE/DISABLE. Typically,the user requests I/O forcing from the programmingterminal. Once requested, the programming terminaldownloads the forced 1/0 points into the appropriatePLC 1/0 image table. Some PLCs keep the I/O pointforced for one scan, after which time the I/O point isautomatically returned to normal operation. OtherPLCs require a FORCE OFF command to return the1/0 point to normal operation.

Forcing is useful in debugging the program andverifying proper operation of outputs and theirconnected equipment, but can be disastrous if not usedproperly. Forcing after installation causes real processevents (valves to close/open, motors to start/stop, etc.)to occur. Important equipment such as safetyinterlocks, motor hold-in contacts, and other safecircuits can be bypassed or modified by forcedconditions, increasing the probability of damage toproperty or life. Forced conditions should be avoided

NUREG/CR-6090 38

Appendix A

as much as possible after the PLC has been installed. Inaddition, once an I/O point is forced it may not bereturned to normal operations. Most PLC systemsremove all forced 110 points once the programmingterminal is switched off or disconnected from the PLCcommunications port. The user must be knowledgeableabout the plant process, the PLC system, and thecharacteristics of the forcing command to properly useforcing. Further, in safety application, the forcingcommands should be used only with strictadministrative control.

8.2. Select Devices

Tape drives, floppy drives, hard-disk drives, andcompact disk 'drives are all available to provide storageof program and PLC system status. Printers of all sortsand varieties are available. Some newer and perhapsmore interesting devices are graphic display terminals,emulators and simulators.

Graphical displays are used to monitor and sometimescontrol the plant process. The display representsmotors, pipes, valves, tanks, and other processequipment with graphical objects. Important data isoverlaid on those objects. The PLC system networkrequires high data transmission rates to supportgraphical displays. If the system network is not fastenough, the terminal may not display the most currentdata. In addition, the communications between the PLCprocessor and the graphic display terminal may delaythe processor's reaction to a system fault or requiredprocess change.

A few PLC manufacturers offer simulators, but mostsimulators must be purchased through third-partyvendors. Simulators may be either special packagedunits independent of the PLC system or I/O modulesthat mount directly into the PLC racks. The packagedunits can range from simple knobs, switches andindicators to complex CPU-based simulators. 110module simulators replace a specific manufacturer'sI/O module and simulate the module's operation to thePLC processor. Simulators are used to verify correctoperation of the user program, the PLC system(including the processor, communications, and the i/Omodules), and the field devices.

\mulators are software-based tools used to verifyr operation of the program. Emulators allow them ing terminal to operate in the on-line mode

t being physically connected to a PLC system.'~tor reads and solves the logic program and

\the necessary display information to the

programming terminal. The PLC processor or its 1/0modules are never communicated with nor controlled.

Both simulators and emulators are useful tools introubleshooting and debugging PLC software andhardware. In addition, simulators and emulators can beused to play "what if' games and validate correctsystem responses to presented threats.

Personal computers with software to aid in the design,implementation, debugging, emulation, anddocumentation of the application program are oftenoffered by the PLC manufacturer.

9. PROGRAMMING

All PLC manufacturers offer programming languages,which attempt to couple program commands withindustrial control functions. Three languages arecommonly used in the PLC industry: Boolean, ladderlogic, and sequential function charts. Booleanprogramming dominants the Japanese markets but israrely seen in the United States or Europe. Ladderlogic is the language of choice for U.S. manufacturers.The most common language in Europe is sequentialfunction charts. Japan and the United States are alsotending towards sequential function charts; some U.S.manufacturers offer both ladder logic and sequentialfunction chart programming.

9.1. Boolean

Boolean programming is a lower-level language. It issimilar to programming in machine language, but ituses fewer commands. Boolean programming usescommon Boolean operators such as AND, OR, NOT,NAND, and NOR. Other arithmetic and logiccommands such as ADD, MULTIPLY, DIVIDE,LOAD, JUMP, and COMPARE are provided. Anexample of Boolean and arithmetic operations inBoolean code is shown below:

LOAD I loads the status of the binary input Iinto a special PLC memory location.

AND NOT J performs a Boolean "AND" operationon the special memory location with anegated binary input J, I AND NOT J.

OUT L sets the binary output L to the statusof the special memory location. L is setto the result of I AND NOT J.

LOAD A loads the status of A into the PLCprocessor's accumulator.

39 NUREG/CR-6090

Appendix A

ADD B adds the status of B into the PLCprocessor's accumulator, adds B to A.

STORE X stores the accumulator status at RAMmemory location X. The result of B plusA is stored at X.

A user with a computer background may preferBoolean programming because of its similarity tocommon source language programining. The difficultywith programming in Boolean is that the plant processcontrol may be difficult to understand. Additionalinformation such as flow charts, English words, orsome other descriptive information may be needed.

9.2. Ladder Logic

Ladder logic was developed specifically to give theprocess control engineer a programming language thatclosely parallels process control drawings. This way atypical process control engineer will understand thePLC program with very little effort devoted to learningthe language. Ladder logic program commands Weredeveloped from ladder logic diagrams. An attempt wasmade to make ladder logic functions a symbolicrepresentation of the equivalent ladder diagramsymbols. This symbolic representation appears insimple relay functions where coils and contacts havesymbolic representations.

Other, more complex functions such as timing relaysand counters are handled a number of different ways

HOT

depending on the manufacturer. In one case thecomplex functions are represented by a square block,and in another case they could be represented by a coilwith special mnemonics. In either case, the necessarycontrol information is input in or near the ladder logicsymbol. Figure A-7 is an example of a ladder logicprogram.

9.3. Sequential Function Charts

Sequential function charts (SFCs) elevate the PLCprogramming language to a higher level. A top-down,object-oriented approach is taken to development,integration and documentation of the process control.The user diagrams the process in the proper sequence,using SFC steps and transitions. A step corresponds toa process control task, and a transition corresponds to acondition that must occur before the PLC processorcan execute the next step or steps. After outlining theprocess, the user programs each step and transition inlower-level graphical tools representing PID) loops,switches, other PLC functions, or 1/0 points. SomeU.S. manufacturers program the steps and transitionsusing ladder logic. In this case, SFCs are a top-leveldiagram showing the ladder logic program flow, just asflow diagrams show computer program flow. FigureA-8 is an example of a generic sequential functionchart. Some of the complexities peculiar to thisexample are not explained here, as each PLCmanufacturer implements SFCs in a different way.

COMMON

A B E

-AC

Symbol Legend

coilN orally openrelay contact

* Normally dosedrelay contact

EControl

FSReset

TIMEROut G

10 Sec.OH

Figure A-7. Ladder Logic Program.

NUREG/CR-6090 40

Appendix A



A user with a computer background may preferBoolean programming because of its similarity tocommon source language programming. The difficultywith programming in Boolean is that the plant processcontrol may be difficult to understand. Additionalinformation such as flow charts, English words, orsome other descriptive information may be needed.

9.2. Ladder Logic

Ladder logic was developed specifically to give theprocess control engineer a programming language thatclosely parallels process control drawings. This way atypical process ýontrol engineer will understand thePLC program with very little effort devoted to learningthe language. Ladder logic program commands weredeveloped from ladder logic diagrams. An attempt wasmade to make ladder logic functions a symbolicrepresentation of the equivalent ladder diagramsymbols. This symbolic representation appears insimple relay functions where coils and contacts havesymbolic representations.

Other, more complex functionssuch as timing relaysand counters are handled a number of different ways

HOT



Sequential function charts (SFCs) elevate the PLCprogramming language to a higher level. A top-down,object-oriented approach is taken to development,integration and documentation of the process control.The user diagrams the process in the proper sequence,using SFC steps and transitions. A step corresponds toa process control task, and a transition corresponds to acondition that must occur before the PLC processorcan execute the next step or steps. After outlining theprocess, the user programs each step and transition inlower-level graphical tools representing PID loops,switches, other PLC functions, or I/O points. SomeU.S. manufacturers program the steps and transitionsusing ladder logic. In this case, SFCs are a top-leveldiagram showing the ladder logic program flow, just asflow diagrams show computer program flow. FigureA-8 is an example of a generic sequential functionchart. Some of the complexities peculiar to thisexample are not explained here, as each PLCmanufacturer implements SFCs in a different way.

COMMON

A B E

-1C I

Symbol Legend

-(>RelayCoil

SF Nornally openrelay contact

4• Normally dosedrelay contact

I:E-1 Control

FReset

TIMERSOut G

10 Sec.Out


NUREG/CR-6090 40

Appendix A



A user with a computer background may preferBoolean programming because of its similarity tocommon source language programming. The difficultywith programming in Boolean is that the plant processcontrol may be difficult to understand. Additionalinformation such as flow charts, English words, orsome other descriptive information may be needed.

9.2. Ladder Logic

Ladder logic was developed specifically to give theprocess control engineer a programming language thatclosely parallels process control drawings. This way atypical process control engineer will understand thePLC program with very little effort devoted to learningthe language. Ladder logic program commands weredeveloped from ladder logic diagrams. An attempt wasmade to make ladder logic functions a symbolicrepresentation of the equivalent ladder diagramsymbols. This symbolic representation appears insimple relay functions where coils and contacts havesymbolic representations.

Other, more complex functions such as timing relaysand counters are handled a number of different ways

HOT



Sequential function charts (SFCs) elevate the PLCprogramming language to a higher level. A top-down,object-oriented approach is taken to development,integration and documentation of the process control.The user diagrams the process in the proper sequence,using SFC steps and transitions. A step corresponds toa process control task, and a transition corresponds to acondition that must occur before the PLC processorcan execute the next step or steps. After outlining theprocess, the user programs each step and transition inlower-level graphical tools representing PID loops,switches, other PLC functions, or I/O points. SomeU.S. manufacturers program the steps and transitionsusing ladder logic. In this case, SFCs are a top-leveldiagram showing the ladder logic program flow, just asflow diagrams show computer program flow. FigureA-8 is an example of a generic sequential functionchart. Some of the complexities peculiar to thisexample are not explained here, as each PLCmanufacturer implements SFCs in a different way.

COMMON

E

Symbol Legend

<RelayCod

Out, G relay contact

S H 4 Normally dosedH relay contact

Out ( I

A B

C D

-44-]ý_E-1 ]Control

FSReset

TIMER

10 Sec.


NUREG/CR-6090 40

Appendix A

S =StepT - TransitionV = Vertical Link

T-001

V

Figure A-8. Example Sequential Function Chart.

9.4. Common Source LanguagesCommon source languages are now being used inPLCs. This is a trend back toward the computerindustry. The language, C, is being incorporated intoladder logic programming. A subroutine block isdesignated in the program. The subroutine symbolizedby the block is written in C. Once the block isprogrammed, it becomes another PLC functionavailable to the ladder logic programmer. A typicalsubroutine block will have a controlled input, binarystatus outputs, analog input data, and analog outputdata. The controlled input initiates the subroutine. Thebinary status output indicates such states as subroutineexecuting, subroutine complete, or subroutine error.The analog input data can be a constant, a memorylocation, or an analog input point, while the analogoutput data is sent to a memory location or an analogoutput point. The C program block allows the user toprogram any control algorithm into the PLC and allowsthe programmer to gain access to any part of the PLC

RAM, including the memory locations used to supportthe operating system.

In addition to function blocks, smart 110 modules areavailable that allow common source languageprogramming. The programming languages used areBASIC, C, or some derivative of these common sourcelanguages. These 1/0 modules are mainly used forcontrol of peripheral devices, but some have beendeveloped to allow quicker real-time response by thePLC system. All of the smart 1/0 modulescommunicate with the PLC processor over the controlnetwork and are accessed by the PLC processor at leastonce per scan cycle.

10. SPECIAL FEATURESSoftware development tools for the PLC makecreation, documentation, testing and modification fareasier than it would be for a system implemented withphysical relays.

41 41 NUREGICR-6090

Appendix A

Some special features have been designed into PLCsystems to help reduce the probability of error whenusing, maintaining or accessing the PLC system. Partsof the PLC RAM may be protected and passwords areused to allow access only to password holders.

For example, one manufacturer provides four levels ofaccess on a particular PLC system. This safety measureprevents unauthorized personnel from accessing and/orchanging certain programs. Depending on the user'saccess level, the user is restricted to certain areas ofoperation which may be: PLC programming, 1/0configuration, reading PLC programs, reading 110configuration, reading PLC data, printing, accessingnetwork devices, and accessing remote 1/O.

A key lock on the programming terminal is a simpleexample of two-level access. The user must have a keyto switch the programming terminal into a mode thatallows PLC programming. Without the key the usercan only monitor the PLC data and program flow.

A special feature to prevent inadvertent 110 modulereplacement is mechanical keying of the 110 moduleand the slot. The 1/0 module and its associated slot inthe 1/0 rack are mechanically configured so no othertype of 110 module will physically fit into the slot.Further, most PLC processors contain a programroutine often called a Traffic Cop. The Traffic Copscans the 110 modules and validates the 110configuration against the current 110 table. If amismatch is generated, the Traffic Cop shuts down thePLC and reports the problem. Also, the Traffic Copallows the user to set-up the 110 con~figuration andspecify the interval in which the Traffic Cop willscrutinize the 110 rack configuration.

11. FAILURESAs in other electronic devices, the PLC can achieve avery high degree of reliability, but failures still occur.High reliability along with failure detection cansignificantly increase the system's availability. Thbissection looks at some of the failures that may have asignificant effect on non-redundant PLC systems.These failures, together with possible remedies, mayalso be used in redundant systems (discussed inSection 12).

11.1. StallingStalling of the PLC processor is perhaps the mostcritical of failures. This failure may be caused by ahardware failure in the PLC, processor or a

programming error. Stalling is relatively easy to detectwith a "watchdog timer" built into hardware. If thewatchdog timer is not reset by the PLC operatingsystem it "times out." Once timed out, the watchdogtimer shuts down the PLC system, and if the system iswell designed, it will send an alarm to the operators. Ifdesigned properly, watchdog timers provide a quickway to detect processor scan failures as well as themost subtle system hiccups. It is important tounderstand that the watchdog timer hardware designand software routines are transparent to the user, andthe details of implementation are seldom published bythe manufacturers.

11.2. Instruction Mis-Execution

Another failure is the PLC processor's failure tointerpret or execute the user-programmed instructioncorrectly. This is caused by a failure in the PLCprocessor, but does not cause the PLC processor tostall. The PLC processor may misinterpret one or morebits in an instruction routine and cause execution of awrong instruction. Complex techniques have been usedto detect subtle failures in the PLC instruction set(Wilhelm 1985), but none of these techniques haveproven fruitful.

11.3. PLC Memory

PLC memory failures may be as small -as one bit or aslarge as annihilation of the entire RAM. A simple bitfailure can cause an instruction to change in meaningor function, or it can cause the inaccurate process datato be sent to the operator or control algorithm.

PROMs are typically validated via checksums. ThePLC processor compares the calculated checksumagainst the checksum stored in the PROM. If amismatch occurs, the PLC is shut down and achecksum error is reported. Depending on themanufacturer, the PLC executes the checksumnalgorithm 'after start-up, after auto-boot, or at specifictime intervals when in rnm-time mode.

RAM memory usually goes through a non-destructivebit pattern test that operates on al RAM, one memorycell at a time. The PLC processor saves the memorycell contents, writes the bit pattern, reads the bitpattern, restores the contents, and compares the writeand read patterns. If a mismatch occurs, the PLC isshut down, the latent memory cells are identified, and amemory error is reported.

NUJREG/CR-6090 442

Appendix A

One maintenance problem is the volatile RAM back-upbattery. If the battery is not properly maintained andthe power is lost to the computer, the battery may nothold the memory's contents. Then when power isrestored, the PLC will be inoperable until the userprogram is restored.

11.4. Intermediate Memory

In addition to the PLC processor memory, othermemory exists in the PLC system. Separate memorymay exist for the I/0 image tables, and intelligent I/Omodules usually contain a processor as well asmemory. The I/O image table memory is typicallychecked by the PLC processor, which places an extraburden on the PLC processor and will certainlyincrease the scan time. For I/O modules with memory,an on-board processor typically handles the memorychecks.

11.5. I/O Address

Some causes of I/O address failures are encoderfailures, decoder failures, communication errors, or anincorrect setting of the address dip switch on the I/Omodule. Address failures are easily handled with theproper diagnostics. A Traffic Cop is an example of aroutine which handles 1/0 address failures. Anotherapproach is to hard-wire the PLC processor addresslines to each 1/0 module. Thus, communication errordetection and correction can be eliminated.

11.6. I/O Module

The I/O module input or output circuitry may fail whilethe communications back to the processor are workingperfectly. For inputs, the damaged hardware may beany component along the input path such as fielddevice power, field device, field wiring, terminationpoints, signal conditioning circuits, or isolationcircuits. Similarly, the output failures can be caused bythe latching, isolation or signal conversion circuits,

termination points, field wiring, field device, or fielddevice power. The field components are mentionedbecause manufacturers are now producing circuitrythat will detect certain failures in the field wiring orfield device.

In output modules the triac is the most commonelectronic device used in the signal conversioncircuitry. Manufacturers are now starting to includefailure detection circuits within these circuits. Themodules detect a triac failure and blow a fuse. Byblowing the fuse the module has a higher probability offailing open, the most common fail-safe state.

Another failure detection 'technique uses anarrangement as shown in Figure A-9. Only one contactis held closed at a time. If the first triac fails, it isdetected, its series contact is opened, and the outputfailure is reported. Now, the second triac can maintaincontrol. If the second triac fails before the first triac isrepaired; the fuse is blown.

One manufacturer markets an evolutionary I/O productthat puts CPU processing power into the I/O modules.Each 1/O module contains an on-board processor,extensive self-diagnostics, and communicationcapability over the manufacturer's proprietary controlnetwork. The system configuration consists of one ormore PLC processors and one or more 1/0 moduleslinked together by a communications network. EachPLC processor on the network can be programmed toselect the I/O it controls. In addition, the system allowsfor redundancy of PLC processors, communicationmedia, and I/O modules. The self-diagnostics withinthe I/O are a key benefit to the system.

During each scan, discrete input modules may bechecked for a failed switch, over-temperature, loss of1/0 power, open wire, and input shorts. The diagnosticused depends on the type of input device and rangesfrom combination of the above four diagnostics to nodiagnostics.

J

FromOutputModule

A-1

ToField Device

Figure A-9. A Failure Delection Technique Used in Output Modules.

43 NUREG/CR-6090

Appendix A

During each scan, discrete output modules may bechecked for a failed switch, over-temperature, loss of1/0 power, no load, over load, short circuit, Load StateFeedback, and a pulse test may be performed. LoadState Feedback indicates the state of the output switchonly, not the load. The pulse test routine uses a pulsesignal to check proper operation of the output point.The pulse is fast enough to have no effect on most fieldoutput devices. The pulse test diagnostic is user-selectable. Depending on the type of output device themodule receives different diagnostics. For example,115 Vac isolated outputs receive all of the diagnostictypes, while relay outputs have no diagnostics.

Analog input modules are diagnosed for under-range,over-range, open wire, high-alarm, low-alarm,intermittent fault, wire error, and input short. As in theother classes of modules, the diagnostics variesdepending on the module type.

Analog output module diagnostics are under-range,over-range, and feedback error. Currently, under-rangeand over-range diagnostics are provided on all outputmodules, while feedback error is provided on only onemodule.

11.7. Infant Mortality

An important area of reliability that is often overlooked is manufacturer testing. Infant mortality ofhardware components in systems is a known failureproblem. Infant mortality refers to the large amount offailures observed in a system during the early part ofthe system's life. Some key tests can be installed in themanufacturing process to reduce infant mortality."Burn-in" testing is a big eliminator of componentswith short life spans. Some manufacturers bum-in at alllevels of manufacturing: components, circuit cards,individual modules, and complete systems. Competentmanufacturers maintain reliability groups that provideresearch on failure issues, testing of the PLC system,corrective action on all reported problems, and recordkeeping.

12. REDUNDANCY

A common feature in all redundant systems is a highlevel of self-diagnostics. Without diagnostics theredundant processors would not be able to detect whento switch over or shut down. The diagnostics shouldsense critical hardware failures, report the fault, andshutdown the 1/0 or PLC system. Also, non-criticalhardware failures should be sensed, annunciated, and

the user logic or operating system should intervene toprovide proper control of the fault.

Many manufacturers offer different levels ofredundancy and redundancy for various components ofthe system. Some of the common configurations of thevarious levels and components are discussed below.

12.1. PLC Processor

The first redundant processor configuration usesduplicate processors. A typical control scheme is tohave one processor control the I/O modules, while theother is an active hot stand-by. A dedicated high-speedcommunication network, which will be called aprocessor-to-processor network, passes the latest 1/0data between processors. In this configuration, theinput image table is passed from the controllingprocessor to the stand-by processor. Then bothprocessors execute identical user programs. At the endof each scan information is exchanged andcomparisons are made. If it can be discerned that thecontrolling processor has failed the stand-by processortakes over control. If a failure is detected, but it is notpossible to distinguish which processor failed, then thePLC system (i.e., both processors, all communications,and all 1/0 modules) is shut down and a processorfailure is reported. The stand-by processor usesadditional diagnostic programs to monitor thecontrolling processor and to initiate takeover upon adetected failure of the controlling processor. The I/O iscontrolled through a control network that allowsmultiple processors and multiple 1/0 on the network(multi-drop configuration is often used). Each of thethree communication networks--the control network,system network, and the processor-to-processornetwork-are independent of each other. See FigureA-10 for a dual processor with single I/O.

Elevating redundancy to three processors brings in theadvantage of two-out-of-three voting. The greatadvantage to two-out-of-three is that a fault in oneprocessor does not stop control of the process. Thetriple redundant processor system is called TripleProcessor with Single I/O and is shown in Figure A-11.As the name implies, this configuration has single 1/0points and three processors. The input point is read byall processors. Usually, a buffer holds the data until allthree processors acknowledge receipt of the inputvalue. The processors execute identical or similarprograms and send the output results to the voter. Thevoter takes a two-out-of-three vote and updates theoutput with the favored result.

NUREG/CR-6090 44

Appendix A

Figure A-10. Dual Processor with Single 1/0.

In addition to the output being voted on, some tripleprocessors vote on ,intermediate results within the userprogram. Via high speed communications, theprocessors share intermediate results. Checks andbalances are designed into the runtime operatingsystem to ensure the results go through two-out-of-three voting. This allows checking of intermediateresults, such as in a cascade PID loop. A cascade PIDloop uses two PH) loops. The first loop receives theinput (process variable) and outputs a set-point to thesecond loop. With intermediate voting, the first loop'soutput could be verified before passing it to the secondloop.

12.2. I/O

Dual redundancy of 1/0 points is typicallyaccomplished with an additional I/O module and theappropriate field wiring, rather than internal I/Omodule electronics. The various wiring configurationsare discussed below. Triple redundancy 1/0 modulesare common with manufactures of triple modularredundant, TMR, systems (discussed in Section 13).

Parallel wiring of discrete inputs yields PLC inputmodule redundancy and increases the reliability of thePLC system. For parallel inputs requiring field power,the power supply must be selected, so it can supplyenough current or voltage to drive the redundantinputs.

For most discrete output applications, a fail-safecondition is the output failing open. This alludes to apotential problem for output modules using triacs asthe signal conversion device. Triacs have a highprobability of failing short. To minimize theprobability of triacs failing short, they can be wired inseries. Now, both triacs must fail short to create a fail-to-danger condition. The fail-safe faults are: one triacfails open, one triac fails short, or both triacs fail open.The only fail-to-danger condition is both triacs failingshort. This control strategy yields an increase in fail-safe faults and a considerable hardening to fail-to-danger faults. Parallel output wiring is desirable inlimited cases where the output must fail short in orderto fail-safe.

45 NUREG/CR-6090

Appendix A

Processor-to-ProcessorNetwork

Figure A-11. Triple Processor with Single I/O.

For relay outputs, series wiring of normally opencontacts is desirable for fail-safe conditions where theoutput should fail open. In the limited cases of failingshort being a fail-safe condition, normally closedcontacts would be wired in parallel.

The analog inputs may be wired in parallel providedthe input signal can drive the two input modules. Foranalog output modules, module redundancy cannot beadded. A redundant field device is required if analogoutput points are to be duplicated. Most analog outputmodules have diagnostics built in and can set theoutput to a desired value upon certain detected failures.

12.3. Communications

Any of the communication networks on the PLCsystem may have dual redundant capabilities. Variouslevels of redundancy are implemented in PLCcommunication systems, three of which are discussedbelow.

The first scheme uses redundant media and switchesbetween media if a fault is detected. The processorverifies proper operation of the main system network.When a failure occurs the processor switches over tothe backup network. This increases the availability ofthe network.

NUREGICR-6090 446

Appendix A

The second scheme is similar but does not useswitching. Instead, the same message is sent out onboth media. This scheme has the added benefit of usingboth messages for error handling routines, speeding upthe data transmission rate by reducing the number ofre-transmissions.

The third scheme uses the two redundant networksindependently. The addressing, data transfer, and allcommunication on each network is totally independent,thereby doubling the transmission rate of the systemwhen both networks are working. When one networkfails, it is detected, and the system communicates withone network.

All three schemes can be elevated to higher levels ofredundancy. Redundant levels greater than three maybe provided in special cases, but none of the majorPLC manufacturers advertise anything greater thantriple redundancy.

13. FAULT-TOLERANTSYSTEMS

The concept of fault tolerance represents an effort toincrease a system's availability despite a limited

reliability. Fault-tolerant systems are~highly available,although not necessarily reliable. Reliability refers tothe probability of component failures, whileavailability refers to the probability that the systemperforms its desired function. Various components of afault-tolerant system may fail while the systemcontinues to perform the desired functions. Thus, thesystem is unreliable, because it needs constantmaintenance, and highly available, because the fault-tolerant design allows the system to perform its desiredfunctions even with a failure in the system. Thefollowing configurations are common in the PLCindustry.

The first configuration, a dual processor with dual 1/0,is shown in Figure A-12. Note that the control networkmay not be connected between the processors in thisconfiguration. This connection depends on themanufacturer's implementation of the network. Amultidrop configuration would allow connection ofprocessors, while a loop configuration would not.

RedundantProcessor-to-Processor

Network

0

0z

0

CD

cc

!

Connections exist on certain co

, 0

zntrol network configurations only.

0

InputModules II

InputModules I

OutputModules I T OutputModules II

To Field Devices

Figure A-12. Dual Processor with Dual I/O.

47 NUREG/CR-6090

Appendix A

The two inputs are typically wired in parallel and eitherinput can initiate a shutdown. The processors' outputimage tables are typically compared after each scan,and a mismatch causes the system to shut down. Theoutputs would be wired to increase the probability offailing safe. Most often, the outputs would be wired inseries, but in very limited cases they would be wired inparallel. Any one of the processors, communicationlinks, or I/O modules can fail, and the system shoulddetect the failure, isolate the failure, and continue tooperate. The primary disadvantage of this system isthat a high number of fail-safe shutdowns occur.Anytime the two processors or the two inputs disagreeand a failure has not been detected, the system is shutdown.

Another configuration is triple processor with dual 1/0.As previously mentioned, the advantage of threeprocessors is that two-out-of-three voting can beimplemented. There is one buffer for each input pointand one voter for each output point. In addition, eachbuffer and voter contain diagnostics, fault detection,and some level of fault tolerance. The 1/0 modules arewired as in the dual processor with dual 1/0 system,but now when a processor fails or two processorsdisagree, the system continues to operate withredundancy. This system can continue to function withone processor, communication link, or VO modulefailed. In addition, the nuisance fail-safe shutdownscaused by a dual processor configuration havingprocessor disagreements are eliminated. Figure A-13shows a triple processor with dual 1O configuration.

Taking the triple processor configuration one stepfurther leads to the triple processor with triple 110configuration. This is a common configuration, oftencalled triple modular redundant (T7MR). TMR allowstwo-out-of-three voting in the inputs, processor, andoutputs. Three inputs are brought into each processor.Each processor executes the user program and outputsthe results. Two-out-of-tiree voting occurs at eachoutput point. This system, shown in Figure A-14,provides the highest availability.

Additional redundant levels may be utilized to improvethe fault tolerance of the system. Currently, PLCmanufacturers offer TMR systems as the highest levelof fault tolerant systems. Two-out-of-four digitalcontrol systems are being designed in the controlindustry, and this may lead to PLC manufacturersusing two-out-of-four configurations.

The processors are usually the most reliable piece ofhardware in the PLC system. By providing redundancyin the processor, the availability of the system is onlyslightly increased. Most manufacturers are aware ofthis and offer redundancy down through the 1/0modules. The following data was calculated usingMarkov models (Frederickson 1990). These data show

the dramatic increase in MTBF that redundancy andfault tolerance can provide. The MTBF for dual ortriplicate processors with single 1/0 is four and fiveyears, respectively. Add dual I/O to each processorconfiguration and the MTBF leaps to 26 and 61 years,respectively. With triple processors and triple I/O theMTBF skyrockets to 18,745 years.

14. PLC CLASSIFICATIONS

Since their inception, PLC systems have grown in sizeand complexity. Most manufacturers rate PLC systemsby the maximum number of allowable discrete I/Opoints, which has lead to an informal sizeclassification:

micro <32

mini 32-128

small 128-256

medium 256-1024

large 1024-4096

super >4096

NUREG/CR-6090 48

Appendix A

Redundant Processor-to-Processor Network

0

z

0

E- I nput Input

-M 1 to 3 Modules I Modules

To Field InputDevices

VFter igure 1 Poutput Output

2 of 3 Modules I Modules

To Field OutputDevices

Figure A-13. Triple Processor with Dual I/O.

49

Appendix A

High-Speed CommunicationsI

I

0

z

0

E-wVu

BufferInput

1 to 3 Modules I

VoterOutput

Modules I 2 of 3

Buffer Input

1 to 3 ModulesII

Output Voter

Modules 2 of 3II

LBuffer1to 3 Input

Modules oIII

To Reid InputDevices

VoterOutput 2 of 3

ModulesIII

To Field OutputDevices

Figure A-14. Triple Processor with Triple 110.

NUREGICR-6090 50

Appendix B:Application of Programmable Logic

Controllers in Safety Shutdown Systems

J. Palomar

R. Wyman

Manuscript Date: June 30, 1993

Contents

1. Introduction .............................................................................................................. 552. coScope ................................................................................................................... 5 553. Documentation........................................................................................................... 554. PLC Life Cycle Issues ................................................................................................... 56

4.1. Project Management.............................................................................................. 564.2. Safety Analysis ................................................................................................... 57

4.2.1. Safety Considerations ..................................................................................... 574.2.2. Availability ................................................................................................ 604.2.3. Hazard Rate................................................................................................. 61

4.3. The PLC-Based ESD System .................................................................................... 614.3. 1. Hardware Selection........................................................................................ 614.3.2. Software Development.................................................................................... 614.3.3. PLC-Specific Considerations ............................................................................. 62

4.4. Testing............................................................................................................. 624.4.1. Hardware Test ............................................................................................. 624.4.2. Software Test .............................................................................................. 634.4.3. System Integration.......................................................................................... 634.4.4. System Test................ ................................ 6...... 634A4.5. System Final Acceptance Test........................................................................ 0.... 63

4.5. Installation ............................ ............................................................................ 634.6. Maintenance....................................................................................................... 65

4.6.1. Hardware Maintenance .................... .......................... -..-..................... 0........... 654.6.2. Software Maintenance ............................... .................. 0.................................-65

4.7. Modifications....6......................................................00....................... o................... 664.7. 1. Hardware............................... ...................................... ............................... 664.7.2. Software ................ ............... ............................................ 0............. -... 0.66..

5. Comparative Design Implementations.................................0............................................. 6...o665.1. Electrical System-Relay Based ........... ...6...........................0........................... 6........... 675.2. Electronic System--Solid-State Based............................o.................................... o...... 0... 695.3. Programmable Electronic System-PLC ....................................................................... 70

6. Application Examples..........-......................... ........ ........ ........ ...... 6................... 6......... 6.... 6.......... 746.1. All Side Construction, Inc ........................................................................................ 746.2. Flour Daniel, In............................746.3. General Electric................................................................................................... 756.4. PLC Structured Programming.....................0 ............................................... 0............... 756.5. PLC Qualification Testing.................................................. o..................................... 766.6. PLC Software Bug................................................................................................ 766.7., PLC Safety Concerns .... ................................................................................... 77

7. emrRemarks .... ............. ......... ........ 0........... .................................. 0.....................................797

References ...... 6..................... ................................................................... 0.................. 81

53

Figures

Figure B-1. Engineering and Test Flow D iagram .................................................................................................. 58

Figure B-2. A vailability Com ponents ......................................................................................................................... 60

Figure B-3. Piping and Instrum ent D iagram .......................................................................................................... 67

Figure B-4. Relay W iring D iagram .............................................................................................................................. 68

Figure B-5. Solid-State W iring D iagram ............................................................................................................. 69

Figure B-6. Solid-State Logic D iagram ...................................................................................................................... 70

Figure B-7. PLC W iring D iagram ............................................................................................................................... 71Figure B-8. PLC Ladder Logic D iagram ..................................................................................................................... 72Figure B-9. PLC System ............................................................................................................................................. 73

Table 1. Dangerous Failure MTBF of Various PLC Systems .............................................................................. 77

Table 2. A vailability of V arious PLC System s .................................................................................................... 78

Table 3. H azard Rate of Various PLC System s .................................................................................................... 78

54

Appendix B:Application of Programmnable Logic

Controllers in Safety Shutdown Systems

1. INTRODUCTIONThis document provides an overview of the use ofprogrammiable logic controllers (PLCs) in emergencyshutdown (ESD) systems. The intent is to familiarizethe reader with the design, development, test, andmaintenance phases of applying a PLC to an ESDsystem. Each phase is described in detail andinformation pertinent to the application of a PLC ispointed out.

2. SCOPEESD systems are required to be both fail-safe andhighly available to mitigate the effects of accidentswhen they occur. PLC systems can be applied to meetboth ESD requirements, but careful consideration tosafety must be given throughout the life of the system.Because of their great flexibility, ease of interfacing,and cost-effectiveness, the PLC-based ESD system isgaining wide acceptance. There is, however, a greatneed for standards that directly address these

*applications. Currently, documents are being writtenby various experts and committees to address the usageof PESs in safety applications. This paper presentssome of the ideas developed in those documents.

Most PLC applications are not publicized via tradejournals or conferences. Of the few applications thatare publicized, only a handful are ESD applications.More of the documentation is written to convey thedesign principles that should be employed whendeveloping a PLC-based ESD system.

For this reason this document concentrates on PLClife Cycle Issues. This discussion covers the designprinciples and examines techniques of projectmanagement, safety analysis, design, testing,installation, and maintenance over the life of thesystem. Section 5 offers several comparative designimplementations, while section 6 highlights theimportant points discussed in first part of the document

and provides some examples of PLCs in ESD systems.This document represents a consensus on whichelements make up a safe and highly available system.

3. DOCUMENTATIONThroughout all phases of the life of a project oneimportant element stands out: documentation.Documentation that reflects the current state of thesystem is an invaluable tool. Dennis A. Inverso (1991)points out:

"Documentation is defined as a vital, recordedinformation base used during all phases of developingand maintaining a Programmable Electronic System

The development, use, and maintenance of a system'sdocumentation can dramatically improve the qualityand safety of the system. Documentation obviouslyprovides the foundation for understanding the system.In addition, the development and maintenance of thedocumentation facilitates communication among thevarious disciplines; operators, system designers,programmers, instrumentation and controls engineers,electrical power system engineers, and maintenanceand management personnel. The documentation, then,provides a platform for intense scrutiny of the system.In Section 4, PLC Life Cycle, Issues, the types ofdocuments needed for each phase, the specificelements included in each document, and theimportance of each document are detailed.

In any project, one of the initial steps should bedefining the necessary documents. The initial list ofdocuments does not need to be rigidly followed, butshould be used as a tool to provide comprehensiveinformation about the system. As the projectprogresses documents may be added or deleted and thedefinitions may change. But this list, like any otherproject document, should be maintained so that itreflects current thinking.

Appendix B

There are three main phases in producing andmaintaining quality documentation; writing, reviewing,and updating. The documents must contain as muchdetail as necessary, while staying within thedocument's scope. Thus, the person writing thedocument must be proficient at the required disciplineand he or she must also be capable of clear and concisewriting. This point cannot be too highly emphasized-it is unimportant how much the author knows about thesystem if he or she cannot convey this understanding toothers through the written word.

Care must be taken in selecting a review team for eachdocument Each review team should comprisecompetent persons from the appropriate disciplineswho can analyze the functionality described in thedocument. Their concern should be with assuring theclarity and completeness of the documentation.

Finally, there must be a formal process for changingthe documentation. Any time a project change is madeall documents which might be affected must bereviewed to see if changes are needed. Once adocument is changed a comprehensive review must becompleted. Document maintenance over the life of aproject is a critical activity.

4. PLC LIFE CYCLE ISSUES

The requirements for good configuration and projectmanagement of a PLC system are no different from therequirements of any ESD system. A brief discussionwith references to standards is presented onconfiguration management. Next, safety analyses ofPLC-based ESD systems are discussed. Finally, theremaining parts of this section address specific PLCissues in various phases of the project life cycle.

4.1. Project Management

All projects, including those that contain PLCs, canbenefit from good project management. Severalstandards, including MIL-STD-1456A, MIL-STD-483A, IEEE-828, MIL-STD-1521B, IEEE-1042, MIL-STD-499A, and IEEE-1058.1, address this issue.Through implementation of these standards, thedecisions and changes made over the life of the projectcan be well controlled and well documented.

MIL-STD-1456A addresses the top-level managementof the project, which is the configuration managementplan. This plan describes the methods and proceduresto be used to manage the functional and physicalcharacteristics of the project. It describes the

documents necessary to define the roles of all personalassociated with the project, to define the hardwareconfiguration, to define the software configuration, todefine all interfaces, and to provide traceabilitythroughout the life of the project for reviews andaudits.

MIL-STD-483A goes beyond MIL-STD-1456A andprovides more detail on the contents of the elements ofthe configuration management plan. MIL-STD-483Adetails the implementation and documentation requiredfor the following areas:

* Configuration Identification• Configuration Management

" Configuration Control

* Configuration Audits* Interface Controls

* Engineering Release Control

* Configuration Management Reports/Records.

Similar to MIL-STD-483A, IEEE-828 providesspecific requirements for a software configurationmanagement plan. Each section of the softwareconfiguration management plan is listed and describedin detail. In addition, examples are presented to helpclarify the contents of the plan.

MIL-STD-1521B describes, in detail, the requirementsfor reviews and audits throughout the life of theproject. Figure B-i below summarizes the contents ofMIL-STD-1521B.

IEEE-1042 suggests ways to apply a configurationmanagement plan. This standard interprets how to useIEEE-828, addresses the issues involved in establishingconfiguration management on a project, and presentssample plans that illustrate configuration managementplans for various types of software based projects.

Establishing and documenting a project managementscheme can aid in successful completion of a project.MIL-STD-499A addresses project management from asystem engineering point of view. The standard defineshow to establish an engineering effort and a SystemEngineering Management Plan. Specifically forsoftware, IEEE-1058.1 defines the contents of asoftware project management plan.

NUREG/CR-6090 56

Appendix B

4.2. Safety Analysis

The military standards mentioned above address theissues involved with project management. They do notaddress safety analysis. The safety analysis entailsvarious safety studies completed and documented atvarious phases of the system's life. Some safetyanalysis tools are FMEA, fault tree analysis, andCMFA. A complete safety study should be completedafter the System Design Review, the HWCI/SWCICritical Design Reviews, the System FormalQualification Review, and periodically throughout thelife of the system. These reviews are identified inFigure B-1.

Maintaining and improving the safety level of a systemis a continuous effort. A one-step safety analysis isinsufficient, because any change may introduce a fail-to-danger fault Therefore it is critical to documentevery problem discovered over the life of the systemand the steps taken to correct the problem, including asafety analysis of the change. This documentation canprovide a good foundation for renovations andchanges, and for the design of future systems.

The safety analysis described below should occur afterthe System Design Review and should be verified afterthe HWCI/SWCI Critical Design Reviews, the SystemFormal Qualification Review, and routinely verifiedafter final acceptance.

4.2.1. Safety Considerations

Any system which presents a hazard to life, the public,or the environment can be thought of as two distinctsystems: (1) the system that does the main work of thesystem, and (2) the protection or ESD system that iscalled upon to make the overall system safe in theevent of a malfunction of (1). If it is assumed that thefailure rates of these two subsystems are independent,then the probability of the occurrence of a hazard thatis unprotected is the product of the probability of afailure in (1), which creates the hazard, times theprobability that the ESD system will be unavailable.Systems in which the control and ESD systems sharecomponents will require more complex dependentprobability analysis. Thus, once the hazard rate of (1)is known, the necessary design using ultra-reliablecomponents and redundancy can be done for the ESDsystem to bring the unprotected hazard rate down to therequired level.

For any system that may present a hazard to life or thepublic safety, a philosophy on safety andenvironmental concerns should be written. Hazardsshould be identified and parameters for eachquantified. Actions required of the ESD system shouldbe specified for each hazard. This analysis is input intothe system design. The safety parameters includeprobability of occurrence, time to respond before acatastrophe occurs, specific process controlconsiderations to address the hazard, and accessibilityof necessary equipment to mitigate the hazard. Alongwith documenting the hazards and parameters, allassumptions and explanations need to be documented.Enough justification should be written so a typicalengineer can understand how and why the safetycalculations and decisions were made.

A number of papers describe and reference variousapproaches to safety quantification, including SaudiAramco 1990, Balls 1991a, Balls 1991b, Bryant 1976,Fisher 1990, Frederickson 1990, Gruhn 1991, Healthand Safety Executive 1987, Inverso 1991, Magison1979, Paques 1990, and Sparkman 1992. Withoutappropriate quantification there is no real foundationfor the proper decisions.

Additional items which will improve the level of safetyof a system are listed below:

" Shutdown devices should be easily accessible andclearly identified.

" The power-up sequence should force the systeminto a safe state before program initiation.

" The PLC should provide diagnostics to isolateinternal and output module faults.The PLC should monitor auxiliary power supplies.

" There should be strict control of all ESD programs

to prevent casual modification." Documentation should be kept up to date.

Code should be modularized to simplifyproduction and maintenance.

" Pulsed signals should be used to turn safety

devices on and off.• The system should be extensively tested,

including testing with fault conditions.

57 NUREG/CR-6090

Appendix B

PrepareHWCITest

Procedure

PrepareSoftware

TestSpec

CriticalDesignReviewHWCI

SystemReqmntsReview

SystemDesignReview

CriticalDesignReview

CSCI

HWCIDevelop.

Spec

(Draft)HWCIProductSpec

(Draft)System

SegmentSpec

SystemSegment

Spec

DBDD

Software IDetailedDesign

Document

I-* --------- -System IAllocatedFunctional Allocateddentification Identification

SystemFunctionalBaseline

AllocatedBaseline

ProductIdentification

Figure B-1. Engineering and Test Flow Diagram.58NUREGICR-6090

Appendix B

PrepareSystem

Perform TestSystem ReportsTests

Perform rPreparePefowarm SoftwareSoftware Test

Tests Reports

Functional Physical FormalConfig Config QualAudit Audit ReviewHWCI HWCI HWCI

System System SystemFunctional Physical Formal

Config Config QuallAudit Audit Review

Functional PhysicalConfig ConfigAudit Aud itCSCI CSCI

HWCIProductSpec

CONFIG

CSCI

- Configuration

- Computer SoftwareConfiguration Item

DBDD - Data Base Design

HWCI - Hardware Configuration Item IIDD - Interface Design Document

IRS - Interface RequirementsSpecification

SoftwareProduct

Spec

QUAL - Qualification

REQMNTS- Requirements

SPEC - Specification

Develop mentalConfigu ration (CSCI Only) -------------bpd

ProductIdentification

ProductBaselineNote: Actual time phasing of activities

must be tailored to each program.

Figure B-1. Engineering and Test Flow Diagram (continued).59 NUREG/CR-6090

Appendix B

4.2.2. Availability

IEEE defines availability as the degree to which asystem or component is operational and accessiblewhen required for use. It is often expressed as aprobability (IEEE). Availability is defined as:

A = Uptime / Total Time

where

A-Availability

Uptime-Time the system is working.

Total Time-Total mission time or time the system isneeded to watch over the plant while theplant is in operation (excludes time forplant shutdowns).

or

A = MTBF / (MTBF + MDT)

where

MTBF-Mean time between failures.

MDT-Mean downtime.

These two definitions are essentially the same. SeeBalls 1991a, Balls 1991b, Fisher 1990, Gruhn 1991,Heron 1986, M. Smith 1991, and Walczak 1990 formore information.

MDT can be broken down into:

MDT = MTDF + MTTR

and

MTTR = MTDL + MTRF + MTRO

where

MTDF-Mean time to diagnose the presence of asystem fault.

MT'TR-Mean time to repair.

MTDL-Mean time to determine a fault location.

MTRF-Mean time to replace a faulted component.

MTRO-Mean time to return the system to operablecondition.

The relationships between these various componentscan be seen in Figure B-2, below. Like reliability, thedesired availability of the system should be clearlydocumented. Estimates of the various constituents ofavailability need to be made and the desired systemavailability needs to be determined. The acceptableavailability will depend heavily on the desired hazardrate. Again, it is important to document all steps anddecisions used to reach the availability number. Also,any changes should be documented, along with reasonswhy the changes were made.

Fault Fault

dMTBF

.MDT Bob

-*-.MTDF-1m-

C e ,rC

-- • MTTR

-og-MTD MMTRF+ MTRO-I.-

AI II I

r

?t-r~ot2 !

4---System operational-b.-

Figure B-2. Availability Components.

NUREG/CR-6090 60

Appendix B

4.2.3. Hazard Rate

Hazard rate is the rate at which risks to life, the public,or the environment will occur. The hazard rate can bewritten as:

H=DxU

where

H--hazard rate.

D-probable demand rate for system safety action.

U-unavailability (1 - A) of the ESD system,assuming that D and U are independent (Balls1991a).

Hazard rate is the measure that relates the systemavailability and reliability to the concerns for safety.How low the hazard rate should be is determined byacceptable industry standards, the people at risk, andthe plant managers. Of course, the hazard rate can notequal zero, but neither should the hazard rate beoutrageously unacceptable by any of the groupsmentioned above. The process of deciding what theacceptable hazard rate is and the means to achieve itshould be clearly indicated in the documentation of thesafety analysis.

4.3. The PLC-Based ESD System

Up to this point this paper has focused on issuespertinent to any ESD system. Below, this paperaddresses concerns specific to PLC systems.

4.3.1. Hardware Selection

Hardware issues in a PLC-based ESD system are notvery different from the issues needing consideration inany PES used in an ESD system. A few PLC-specificitems are discussed below.

Once the configuration management and systemrequirements are detailed, the decision whether or notto use a PES may be made. Different systems shouldbe evaluated, including PC, PLC, DCS, and SCADAsystems. A thorough analysis of each system reviewedshould be documented. Some scheme should bedeveloped to show how each of the systemrequirements is met by each of the systems underconsideration. It is particularly helpful if a numericalscoring system can be applied to this scheme so thatthe systems under consideration can be rankedaccording to their ability to meet the requirements,including reliability requirements.

The selection process must also include theconsideration of the operating software that will beprovided as part of the PES system underconsideration. A vendor's method of collectingsoftware fault reports and correcting software problemsneeds to be thoroughly understood and evaluated. If avendor's software development process is visible, itshould be evaluated to verify that the necessaryQA/QC methods are in place to ensure that reliablesoftware is being produced. And finally, fieldexperience with the software being considered is aninvaluable predictor of the kind of experience a newuser may expect to have.

In making a selection, data from user groups can bevery important. These groups are specialized toparticular vendors and are formed to address systemproblems. They usually have considerable leveragewith the vendor and can force necessary changes andguide future direction. A vigorous and active usergroup'is usually an indicator of a successful product.

With the above data in mind, a choice can be made ofthe PES that best meets the needs of the system.

PLC systems provide a cost-effective solution tosystems that have high number of 1/0 points. Themajor disadvantage of PLC systems is that they havepoor user interfaces compared to PC, DCS, andSCADA systems. The PLC user interface typicallyconsists of a programmer's terminal that displays aladder logic image to be manipulated. Debugging toolsallow the user to follow the flow of the power throughthe ladder logic image. Many of the special functionssuch as PID algorithms, math functions, and timers aredifficult to implement, and process data can only beviewed with the programmer's terminal. Most PLCmanufacturers are aware of the poor user interfaceattributes of their systems and are making efforts toimprove them. Some items appearing on the market aregraphical terminals to display process data, easiermethods to program special functions, state-basedprogramming, sequential function charts, and personalcomputers to provide better debugging, testing, anddocumentation.

4.3.2. Software Development

The reason for the development of PLC systems andother industrial PESs was to allow process controlengineers and technicians to apply digital computertechnology to process control applications, withouthaving to learn the details of typical digital computerprogramming. Specialized languages and interpreters

61 NUREG/CR-6090

Appendix B

were developed by the vendors, and these languagescould be used by the process control engineer withvery little training. PLC ladder logic is an example ofsuch a language.

As these systems became more widely used,techniques were developed, usually by learning frombad experience, which tended to make the systemsmore reliable. Some of these techniques are describedbelow.

4.3.3. PLC-Specific Considerations

The correct contact instruction must be selected for thedesired circuit operation of the field device. The ladderlogic program should be developed based on the PLCinput points, not on the wiring configuration of theinput devices. Two good rules to follow are:

(1) If the wired configuration of the field input deviceand the desired function in the circuit are thesame, program the ladder logic input instruction asa normally open contact.

(2) If the wired configuration of the field input deviceand the desired function in the circuit are opposite,program the ladder logic input instruction as anormally closed contact.

The number of duplicate contact instructions should bereduced to a minimum, especially where a singlecontact instruction that is referenced to an existing coilinstruction would suffice.

The use of positive feedback "seals" is recommended.An example of a positive feedback seal is a signalexternal to the PLC system which "seals in" a startswitch to a motor. The project team should use themotor contactor auxiliary contact as a PLC input andthe program should use this input to determine if themotor has started. The PLC output coil used to initiatea motor start should not also be used to verify themotor has started. In this way, the program indicateswhen the motor starts/stops, not when the motor hasbeen requested to start/stop. Also, accidental restarts ofthe motor are reduced.

For critical applications, the use of auxiliary contactssuch as those described above may not be adequate,since the auxiliary contact only indicates that the motorstarter has picked up, not whether or not the motor hasstarted. This is only one example of secondary sensingof a signal. Whenever a parameter must be sensed, theuse of secondary sensing should be critically examined

to determine what the consequences are if thesecondary sensor indicates that the parameter is validwhen, in fact, it is not valid.

The programmer should not program latched outputsthat stay latched through power cycling. A holdingcircuit with "seal-in" contacts, commonly done withrelays, should be implemented in the PLC program.This will eliminate the inadvertent turning on ofmotors, pumps, etc., when system power cycles.

4.4. Testing

Testing is a necessary part in the development of anyESD system. Testing may, however, turn up systemdeficiencies that require changes to be made in theimplementation. Some of the changes are clearlybenign, reflecting only errors in the implementation.These require changing the implementation, but thedocumentation is not changed since the documentationis correct.

Some changes, however, are a reflection of incorrectoperation because of misunderstandings ofrequirements, or requirements or specifications that arein error. When such problems are detected, thereshould be a thorough review of the system sincefundamental changes in the system design mayintroduce problems unless such reviews are held.

Finally, all changes should be documented, whateverthe cause. Discrepancy reports should be issuedtogether with resolutions so there is completetraceability of all of the changes made. Updatingsystem documentation as changes are made is a criticalactivity since this is an area which can easily get out ofhand in the rush to get a system into operation.

4.4.1. Hardware Test

The components of the system, the subsystems, and thecomplete system need to be tested. These tests mayoccur at various sites and be performed by variouspeople. The key is not by whom or in what location thetest is completed, but that the test is completed,documented and independently verified.

If the manufacturer is supplying a complete hardwaresystem, then the manufacturer should be required to doall component and subsystem testing with the projectteam periodically reviewing the manufacturer's testsand documentation. If the project team is purchasingand building the hardware, a team independent of thedesign and development team should complete all

NUREGICR-6090 662

Appendix B

testing, although this is not typical in the industry. In,any case, all failures during testing should be welldocumented with the necessary safety parametersrecorded (MTBF, WITT, MTTR, etc.). These statisticscan be invaluable in predicting ultimate reliability.

All hardware functionality should be tested. Inaddition, the hardware needs to be tested to ensure itmeets the requirements of the hardware design and thesystem design. All interface specifications between the1/0 modules and field devices should be verified. Inaddition, the 1/0 modules should be connected andexercised with loads having identical impedances tothe field devices they will be operating.

4.4.2. Software Test

Typically, software is used to minimize hardware or tosolve complex problems that are difficult to solve withhardware. The inherent complexity of software has ledto a lively public debate on the question of how toverify that software is reliable, dependable, and safe.Although comprehensive discussion of the best way totest software is out of the'scope of this paper, a few keyideas will be presented and some sources of additionalinformation will be listed.

Although there is no way to "prove" that a softwaresystem is reliable, confidence can still be gained byvarious testing methods. Further details on softwaretesting and metrics can be found in Humphrey 1989,IEC-880, Parnas 1991, Sandia 1987b, and Sparkman1992.

All software used-including the software developedby the project team and that supplied by the PLCvendor-must be tested to some extent. Thefunctionality of all pieces of software should beexercised and failure records should be kept. For thesoftware that is produced outside the project team,reliability statistics should be obtained from thesoftware manufacturer if possible.

One source of reliability statistics for purchasedsoftware is user groups. These groups usually have avested interest in the success of particular softwareproducts and are only too happy to publicize problems,as this kind of publicity is a strong lever for forcing asoftware vendor to make necessary changes.

4.4.3. System Integration

If good practice has been followed to this point, theprocess of systems integration should have very few

difficulties. The hardware and software should meetthe system requirements defined earlier in the program,and any changes in hardware or software that affectedthe system requirements should have been resolved.The system integration difficulties should, for the mostpart, consist of overlooked items.

4.4.4. System Test

A PLC system can be purchased either as a completesystem from one manufacture or as separatecomponents to be put together on site by the projectteam. Either way the system needs to be thoroughlytested with all the PLC hardware, all the software (withno modifications for test purposes), actual field deviceswhere practical, and simulators where the use of theactual. field devices is not practical. The simulationhardware should duplicate the impedance, responsetimes, and other pertinent characteristics of the fielddevices. If the PLC vendor is supplying the completesystem, the system should first be checked at thevendor's site. This way hardware changes are easy toimplement and, typically, the project team will stillhave maximum control over the vendor's performance(e.g., a major payment to the vendor is usually madeafter delivery).

The processor scan time desired should be verifiedagainst system requirements. This can be done bymeasurement or calculation.

Careful design that includes attention to systemresponse time, co upled with thorough debugging,simulation, and verification, will reduce timingproblems. To avoid common timing problems,sufficient time must be given for each mechanicaldevice to settle to a steady state before starting the nextstep in a sequence. Careful design will also help toprevent the occurrence of "infinite loops," whichdevelop when one event unexpectedly triggers otherevents, and a circle of such events is created.

4.4.5. System Final Acceptance Test

The System Final Acceptance Test should require acomplete run of all functional tests for a specifiedperiod of time with a maximum number of allowablehardware or software failures. This will provide a test'on the MTBF requirements as well as functionality.

4.5. Installation

Proper inst allation is a critical factor in reliableoperation of the hardware. Most PLC manufacturers

63 63 NUREG/CR-6090

Appendix B

offer installation guidelines with detailed explanationsoutlining how to properly install their PLC systems.Items to consider are:

1 /0 module to field device interface compatibility." Proper environment (temperature, humidity, air

filtering, etc.).* Industry standards and good practice for

fabrication and wiring." Proper wire bundling and labeling.0 Proper connector labeling.

" Proper strain relief on all cables and wires." Proper grounding of all equipment." Avoidance of ground loops.* Segregation of AC, DC, and communications

wiring.* Use of shielded cable for analog, pulse, or high-

frequency signals." Use of secure connections (terminal blocks, twist

lock connectors, etc.)." Layout of the equipment for easy access to high-

.maintenance items." Proper lighting and space near equipment for

maintenance personnel." Electrical transient protection where needed.

Following are additional items for which care shouldbe taken during installation.

Output devices should not be connected in parallel forhigher current carrying capacity. Output devicespecifications will not guarantee simultaneousswitching for identical devices. Thus, if two identicaldevices are connected in parallel, the first one to turnon will be excessively stressed. Also, the "ON"resistance may be different in each device, causing thecurrent division to be unequal. This may also causeexcessive stress in one of the devices.

Connecting output devices in parallel to increaseciurrent capacity causes an abnormally high rate offailure (Wilhelm 1985). The proper desig~n will use one

switching device with the proper interface. If paralleloutput devices are desired for a fail-safe design, theneach output device should be rated to properly handlethe full load.

Inadequate protection against electrical transients canbe a cause of random hardware failures. Following aresome items that need electrical transient protection, aswell as some protection suggestions.

Output modules and field devices withswitches/mechanical contacts may need de-bouncing orsurge suppression. Mechanical contacts bounce whenclosing. A properly designed circuit will filter out thisbouncing and produce a clean transition.

An inductive DC load connected to an output moduleshould have a diode in parallel with the load to handlethe surge when the inductor is switched off. This surgewill create a voltage spike that may damage the outputmodule if there is no suppression mechanism. Thesediodes are commonly referred to as back-emf diodesand may be incorporated within the output module.

The proper interface design between the 1/O moduleand the field devices is of utmost importance. Someoutput modules "leak" when in the OFF state, and ifsuch a module is driving a high-imnpedance load theload may not turn off. Some input modules may havetoo high or low an impedance for the source and sooperation may be erratic or improper. Also, inputmodules with high input impedances may beexcessively noise-sensitive unless proper steps aretaken.

The PLC system should have its own isolated powersource and, if the system requires it, a UPS. Devicessuch as motors, generators, welding equipment, andheating devices, which tend to produce substantialnoise on the power lines, should not be placed on thesame electrical circuit as the PLC system. If properlydesigned, a voltage regulating transformer can be veryeffective. A separate receptacle on the same isolatedelectrical circuit should be provided for the PLCprogramming device. This receptacle should beproperly designated for PLC use only and not be usedfor routine maintenance equipment (i.e., drills,electrical saws). Mounting the receptacle inside alocked PLC cabinet can prevent improper use of thereceptacle.

NUREGICR-6090 664

Appendix B

The installation process should be a well thought outand well documented step-by-step procedure similar tothe following example:

Phase 1-Install the system and verify correctinstallation.

Phase 2-Check supply circuits for proper wiring andvoltage.

Phase 3-Energize each device, processor, 1/0module, etc.

Phase 4-Energize all 1/0 circuits, from the modulesto the field devices.

Phase 5-Perform a loop test of each control loop.

Phase 6-Operate the PLC inputs and outputs, withactual field devices where practical.

Phase 7-Installation complete, ready for finalacceptance test.

4.6. Maintenance

The Maintenance discussion is split into two areas:hardware and software. Most PLC manufacturesprovide maintenance information. From thisinformation the project team needs to developmaintenance procedures.

4.6.1. Hardware Maintenance

If the entire PLC ESD system is on a battery-poweredUPS, these batteries need to be routinely checked andtested. The battery voltage needs to be checked forproper level, and a deep-cycle test should be performedroutinely. Additionally, most PLC systems havebattery back-up for volatile memory. The alarms forthe each of these battery systems should annunciatelocally, in the main control room, and in a centralmaintenance room if one exists.

A PLC system with software verification of thehardware I/O module arrangement will catchaccidental insertion of an I/O module into the wrongslot. This piece of software, called "Traffic Cop," isconfigured by the user. The configuration shows themapping of 1/0 modules to PLC slots. Once the TrafficCop configuration is set up the PLC processorroutinely scans the modules and verifies that the I/Omodule configuration is identical to the Traffic Copconfiguration. Not all PLC systems contain thisfeature.

Mechanical keying of I/O modules allows a specifictype of module to be placed in each 1/0 slot. Typically

the manufacturer designs each 1/0 module type with aunique hole pattern on the back, and the user sets theappropriate pin pattern on the slot. Thus, only one typeof 1/0 module can make electrical connection in thatslot. Each module type-digital input, analog input,digital output, etc.-will have a different hole/pinpattern. Not all PLC systems contain this feature.

"Hot-swap" is another convenient maintenance feature.Hot-swap allows replacement of any module (i.e., 1/0,processor, communication, special-purpose) withoutdamage to the module while the PLC system is underpower. Not all PLC systems contain this feature.

When a failure occurs the system should be thoroughlydiagnosed and all hardware problems found andrepaired. It is in many cases easier to make adjustmentsto the software than to try to identify the source of ahardware problem. No changes to software should beallowed without management approval and appropriatedocumentation changes.

There should be in place and in force a system fordocumenting all failures of every type, including thetime each failure occurred, what diagnostics were runand what the diagnostics found, and what was replacedas well as what actually fixed the problem. The time torepair the problem should be recorded, and if thefailure was linked to any previous problems, this factshould also be recorded. From these numbers a truepicture of system availability and reliability can bedeveloped, together with identifications of weak pointsin the hardware.

Failures have two sources: (1) wear-out and breakage,and (2) design flaws. Type 1 failures require onlyreplacement of equipment. Type 2 failures requireconsiderable analysis and are covered in Section 4.7.

4.6.2. Software Maintenance

After start-up there are only a few softwaremaintenance issues to consider such as securing back-up copies of the program and keeping track of theversions. Maintenance personnel may, with appropriateapprovals, monitor the software during troubleshootingor use diagnostic software, but once the systemsoftware is installed, tested, and accepted, it should notbe modified without formal approval. This approvalmust be preceded by a written analysis of the problem,a proposed solution, and a safety analysis to verify thatthe system will not be compromised by the changeproposed.

65 NUREG/CR-6090

Appendix B

Industry practice makes available to the userinexpensive hand held devices which allow set pointmodifications, forcing of I/O points, software changes,etc. These devices have a potential for misuse andcareful control needs to be exercised by supervision toprevent mishaps.

From time to time, over the life of the system, thevendor of the operating software will send updates forthe system or new versions of the system will beissued. Before any of these changes are made, thescope of the changes should be thoroughly understoodas they pertain to the user's system. Finally, thechanges should be installed and a thorough acceptancetest of the system run. If any problems occur, the oldsystem should be re-installed and run until the issueshave been resolved.

A procedure must be established to control access tothe software and assure that the correct version isrunning on the system with back-up copies available.One person, together with an alternate, needs to beassigned the responsibility for maintaining allprograms and programming equipment. The alternateshould be aware of system status (location of backupcopies of the system and the code, current versionrunning, etc.) so that he can handle problems in casethe primary person is unavailable. Back-up copiesshould be stored under lock and key. One convenienttechnique is to place back-up copies in a box lockedinside the PLC cabinet. Software access levels aregood for controlling who has access to what functions.With the use of passwords, software access levels canbe set up so certain people are allowed to program thePLC system, while others may only monitor theprogram and some may not be allowed to access thesystem at all.

4.7. Modifications4.7.1. Hardware

Hardware modifications are the same for the PLC-based ESD system as for any other electronic system.If a hardware design problem is found, the appropriateprocedures-such as those found in MIL-STD-483Aand MIL-STD-1521B--are followed.

4.7.2. Software

Software faults occur during phases of design,development, and modification. The affects of softwarefaults can be more subtle than hardware faults. Also,

some software faults may not be detected for aconsiderable time.

In PLC systems, software modifications are mucheasier to implement than hardware changes, and forthis reason there is a tendency for software changes tobe implemented without reviews. In an ESD system itis important to follow a modification procedure,including thorough reviews, in order to verify that thechange being proposed is the right change to make, aswell as to reduce the number of new faults that may beintroduced into the system by the modification.Changes should not compromise the safety function ofthe PLC.

Another feature which may have a detrimental effecton safety is "on-line programming." Most PLC systemallow on-line programming changes by anyone whocan access the PLC processor. The access can bethrough a hand-held terminal, a computer on thenetwork, or a terminal connected directly to the PLCprocessor. Since the software is very complex and thethreat to safety is real, on-line programming should beprohibited without proper managerial control. On-lineprogramming devices must be strictly controlled.

5. COMPARATIVE DESIGNIMPLEMENTATIONS

To familiarize the reader with a PLC design, a simplePiping and Instrument Diagram (P&ID) is used toimplement a logic diagram and wiring diagram. ThePLC design follows the traditional steps of anyinstrumentation and control design. From a P&ID orsome process/instrumentation diagram(s) the logic isformulated and a wiring diagram(s) is developed. Awiring diagram is required for all electrical designs,while the complexity of the P&ID motivates thedecision to produce a logic diagram. The PLC wiringdiagram is simpler than a system designed with non-computer electrical components and simply depicts I/Omodule connections to sensors and actuating devices.The PLC wiring diagram does not reveal the systemlogic. In a PLC, the logic resides in software and iscommonly displayed to the user as ladder logic. (Tofurther acquaint the reader with PLC systems, FigureB-8 shows various communication networks, I/Omodules, and support devices that may exist in a PLCsystem.)

NUREG/CR-6090 66

Appendix B

Figure B-3. Piping and Instrument Diagram.

Figure B-3 represents the Piping and InstrumentDiagram (P&ID) that will be implemented with threedifferent technologies. The three technologiesexamined are electrical, electronics, and programmableelectronics. The electrical system is relay-based. Theelectronic system uses solid-state devices, and theprogrammable electronic system is a PLC design. Foreach technology the advantages and the disadvantagesare listed and a wiring diagram is shown. Theconfiguration logic is shown for the electronic andprogrammed electronic systems.

The P&ID depicts a system that will shut downfeedwater to a tank upon detection of high water level.Three level sensors furnish signals for 2-out-of-3voting and operator indication. If two out of threesensors detect a high level the voter initiates closure ofthe motor-operated valve, MOV. This example is basedon a less-detailed presentation in Adamski 1991.

5.1. Electrical System-Relay Based

The wiring diagram for a relay-based implementationof this P&ID is shown in Figure B-4 below. Relay-based systems were the first protective systemsinstalled and are still used extensively. The advantagesand disadvantages of relay based systems are specifiedbelow:

Advantages:

" Easy to understand.• High immunity to electrical noise." Highly predictable failure mode (typically > 90%).

Disadvantages:

* Require a lot of space." Complex functions are difficult or impossible to

implement." Complex relay systems are difficult to

troubleshoot.* Large relay systems are difficult to maintain.• All but small modifications are expensive, timing

consuming and difficult." Typically designed to be energized under normal

operation, thus require a significant amount ofpower to operate.

" Continued energization of the coil reduces therelays MTBF.

* Limited to digital I/O.

Referring to Figure B-4, a high water level will openthe level switches LS-1A, 1B, and IC. Opening anyone of the level switches will turn on the High Levelalarm light. Opening any two or more of the levelswitches will drop out the "D" coil and initiate closureof the MOV. Position switch ZS-1 shuts power off tothe MOV when full close position is reached.

67 NUREG/CR-6090

Appendix B

120VAC

Line Neutral

Figure B-4. Relay Wiring Diagram.

NLIREGICR-6090 668

Appendix B

5.2. Electronic System-Solid-StateBased

The wiring diagram for a solid-state-basedimplementation of the P&ID in Figure B-3 is shown inFigure B-5 below. The logic to be programmed in thesolid-state device is shown in Figure B-6 below. Solid-state systems were used in limited cases and are rarelyused now. The advantages and disadvantages of solid-state based systems are specified below:

Advantages:

* Small space requirements.* Easy to test and troubleshoot.

Disadvantages:

0 Failure mode closer to a 50-50 split.

" Limited diagnostics, typically LEDs connected toselected output points.

" Logic modifications are difficult.

* Obsolete hardware is difficult to obtain andmaintain.

• Contains only digital 1/0.

In the Solid-State Wiring Diagram (Figure B-5) thesolid-state device inputs are on the right side and arelabeled 11 through 14. A common neutral for all fourinputs is shown. The solid-state device outputs are onthe left side, are labeled 01 through 04, and have acommon neutral as shown.

In the Solid-State Logic Diagram (Figure B-6), theinputs and outputs are designated as 11 through 14 and01 through 04, respectively. Boolean logic operatorsare used to show the relationship between the inputsand outputs.

120VACLine Neutral

LS-1A

LS-1 B

LS-1 C

ZS-1

F

-0

12

-0

14

-0N

M Vl)

0 LVl)

0

01

02

03

0-

04

N

70 K

-El-

High Level -A

High Level - B

High Level - C

Close MOV

Figure B-5. Solid-State Wiring Diagram.

69 NUREG/CR-6090

Appendix B

01

02

03

04

11

12

13

14

Figure B-6. Solid-State Logic Diagram.

5.3. Programmable ElectronicSystem-PLC

A wiring diagram and ladder logic implementation ofthe M&ID in Figure B-3 is shown in Figures B-7 and B-8, respectively. In addition, Figure B-9 depicts the PLCand some of its components. The PLC has been widelyaccepted for control and protection systemapplications. Below are some advantages anddisadvantages of a PLC-based system.

Advantages:

" Requires little space.

* Easy to test and troubleshoot." Contains analog 110." Easy to modify both hardware and software." Complex functions can be implemented.* Includes diagnostic routines." Contains communication links with other systems

in the plant.

Disadvantages:

" Software reliability is difficult to prove." Difficult to control the hardware and software

configuration.

" Expensive to manage the hardware and softwareconfiguration.

" The simplest software error may have catastrophicconsequences (Vitrification plant (HM 1991)-asimple error, the omission of "+" in the program,failed to alarm a dangerous situation that couldhave resulted in the death of an operator.)

In the wiring diagram, the PLC inputs are representedby square boxes with the designation -r' and a number,while the outputs are represented by diamond boxeswith the designation "0" and a number. Typically, thePLC 1/0 module internal wiring is arranged to dividethe inputs or outputs into isolated groups of two or fourthat share a common neutral.

In the PLC Ladder Logic Diagram all contacts areshown on the right side and all coils are shown on theleft side. The contacts controlled by 110 module inputsare designated by an "I" with a reference number. Thecoils that control I/0 module outputs are designated byan "0" with a reference number. The coils and contactsinternal to the PLC and implemented in software onlyare designated by "C" with a reference number. Theinternal coil and its associated contacts have the samereference number.

NUREG/CR-6090 770

Appendix B

120VACLine Neutral

!LS-1A

F ii

LS-1 B

LS-1 C

-TzS-1

Level High -A

Level High - B

/\

Level High - C

C \Close MOV

-40

Figure B-7. PLC Wiring Diagram.

71 71 NUREG/CR-6090

Appendix B

10000 COOOO+--] [--+ -+..+. -+------ -+(-)-+

I0001 COON0

10002 C0002---] [ -- -. . ---------- -+-...... ----....... -- ... - (-

COOO 00000

CO001 00001

C0002 00002+ -- --------- - --------- .-... +.. .. _ .. .... ( .

CO000 C0001 + C0003+--] [--+-- -[ ---+- + --------------I I

COOO C0002!

COOO1 C0002!+--] [--+-] [--+ ,

1 10003 C0003 00003+ -, ] [ --+ - -------- - -. . .. ----. . .+ -.. .. .. --- . .. -+ ( .

+[END]+

Figure B-8. PLC Ladder Logic Diagram.

NUREG/CR-6090 72

Appendix B

Host Computer

Operator's Panel Personal Computer

11 J--------- ---

"Anetwork

-E0

0caJ

0

C.)0

0.2(L

0

a).

0W

0

C)

0

4)z

00

ProgrammingTerminal

Figure B-9. PLC System.

73 73 NUREG/CR-6090

Appendix B

6. APPLICATION EXAMPLES

The literature on applications of PLCs in ESD systemsis very limited. Some documentation has been createdon various applications of PLCs, but most of it doesnot go into much detail. Recently, more literature hasbeen written on the use of PESs in ESD systems.

A few examples are presented and discussed in thissection. Those examples address specific issues ofPLC-based ESD systems. The pros and cons of theexamples are discussed. Three papers that discuss keyelements of the ESD system life cycle are alsopresented. The three papers address documentation,PLC qualification, and PLC safety.

6.1. All Side Construction, Inc.

Smith (1991a) discusses his application of a PLCsystem in an ESD system in conjunction with a DCS.The project was the renovation of a hard-wired relay-based shutdown system used in a petrochemicalcompany's pilot plant. The paper details the areas ofPLC selection, reliability, ESD design requirements,annunciator function, and shutdown bypass concepts.

Five PLC configurations were considered:

1. Single CPU system

2. Hot standby system

3. Duplex system

4. Triplex system with single sensors

5. Triplex system with triple sensors.

For various reasons, but principally cost, the singleCPU system was selected. The single CPU system hadan availability of 99.9947%, according tomanufacturer's published literature, and various safetyanalyses completed at the design level concluded thiswas adequate.

A hazard and operability study (a qualitative analysisof the potential operational error scenarios andequipment failures) was performed. A morequantitative analysis in the form of Fault TreeAnalyses was also performed at the design stage. Thelast consideration was checking for fail-safe operationof the ESD system.

The author puts forward some general principles forESD system design which he feels are critical:

1. ESD system wiring should be separated fromcontrol system wiring so that a disaster that takesout one system's wiring will not take out both.

2. Giving the ESD system a distinctive color tends toprevent inadvertent modification of the system.

3. Critical valves (including manually operatedvalves) should have limit switches on them so thatthe ESD system can sense their position prior tosystem initiation in order to prevent systeminitiation if the valve is improperly positioned.

4. An uninterruptible power supply should be usedwhere needed.

5. Lamp and horn test capability is required.

6.

7.

Regular test and maintenance are required.

Control and protection sensors should be separatefrom each other.

The author does not seem to be concerned about thesoftware component of the system.

There have been no failures of any hardwarecomponents of the ESD system in the four years ofoperation. Smith states that the reliability of the systemhas been excellent, yet no safety statistics are quotedexcept hardware failure rate. The hardware reliabilityappears to have been excellent. No mention is made ofthe engineering change order record.

6.2. Flour Daniel, Inc.

Vora (1991) discusses some of the decisions thatshould be made by an engineering contractor once asuccessful bid for a control system has been won. Thepaper is biased toward the contractor's concerns ofsupplying a system that meets the requirements of theplant owner while allowing a profit to be made by thecontractor. Still, a few good point are made aboutvarious key elements of PLC applications. Voradiscusses the tradeoffs between PLC and non-PLC-based systems and goes on to discuss how to select thebest PLC vendor. The PLC selection factors are listedin great detail and provide a good starting point forusers selecting a PLC system. Another important areadiscussed is the future trends in the PLC market andthe future needs of the PLC users.

Vora points out the great need for some standardizationof the PLC communication networks, operatorinterfaces, and network addressing schemes. Also,diagnostics on most PLC systems need muchimprovement. The diagnostics can be made to reduce

NUREG/CR-6090 74

Appendix B

the maintenance expertise and to help reduce the downtime of the systems.

6.3. General Electric

Walczak (1990) lays out many of the features that heemployed in using a PLC-based system for chemicalplant protection. The chemical plant process involvedhighly flammable and toxic chemicals. One feature ofthe design process was the inclusion of the ESD systemat the very beginning of the design. Because protectionwas built in from the beginning rather than added as anafterthought, the cost was reduced and the functionalityincreased.

Walczak (1990) states the project safety systemobjective very clearly (paraphrased):

The most important function of an emergencyshutdown system is the ability to safelycontrol and stop a process so that no injurywill occur to personnel within the processarea or any other associated area, provideprotection for the plant and associatedequipment, and to prevent pollution of theenvironment.

During the design phase the system was divided intounits of control, and each unit was assigned a safetylevel and priority. The response times required for safeoperation were also determined.

The hardware requirements were developed withspecial consideration for system availability and theSingle Failure Criterion from IEEE-279. To obtain thehigh availability desired, 99.99XX%, redundancy wasnecessary. Also, self-diagnostics were given highpriority to help reduce the system down time.

A "hot spare" redundant system was employed with asynchronizing unit to keep the two units operating instep. Each PLC had its own 11O rack and each rack wasconnected to a redundant 1/0 bus. If the synchronizingunit discovered a failure in one PLC it signaled theother to take over operation, providing a "bumplesstransfer."

Considerable analysis was performed on thesynchronizing unit because of its potential for being asingle point of failure.

The response to various failures was analyzed,including the PLC system's response to its own

failures as well as external failures. The response of thebalance of the system to PLC failures was alsoconsidered.

Considerable space in the paper was devoted toavailability calculations, but no hard statistics wereprovided. The author devoted considerable effort to thequestion of what ought to be done to assure reliablehardware, without commenting on whether or not thevendor used actually performed the necessaryenvironmental tests.

Too much time and effort was devoted in this paper tohardware considerations and almost no mention wasmade of software effort.

6.4. PLC Structured Programming

Keskar 1990 discusses a structured approach toprogramming ladder logic on a PLC. The systemconsisted of a PLC supervised by a PDP-1 1 computer.Because of the complexity of the supervisory control, amethodical and structured approach was decided uponto program the PLC.

Two major problems were identified. First, thecommunications between the PLC and the computerhad to meet real-time performance requirements.Second, several engineers were involved in the effortto program the ladder logic.

The communications problem was not technologicallychallenging but only needed a complete set ofdocumented requirements. Once the requirements wereidentified, the PLC system was designed to meet theserequirements.

Two things were done to deal with the multipleprogrammer problem. First, the problem wasminimized by the use of standard templates forimplementing logic functions. The structured approachto programming ladder logic is highlighted in thisarticle. This technique is equivalent to the use of a setof standard macros in programming. Second, standardnames were given to all of the coils and registers to beused, and standard 1/O assignments were made. Incomputer programming this is equivalent toconstructing a set of global variables for allprogrammers to use.

Keskar outlines a simple approach to structuredprogramming with ladder logic. This structuredapproach helped simplify the debugging of thecomplete software package, helped produce good

75 NUREG/CR-6090

Appendix B

documentation of the software, gave some uniformityto the logic and program regardless of which persondid the work, and made the logic easier to read. Thisexample shows that a structured approach similar tothat used in the computer science world can providebenefits to programming in ladder logic. A great needexists for formal methods and structured approacheslike the one shown here, that deal specifically withprogramming languages used on PLCs.

6.5. PLC Qualification TestingEkkehard Pofahl ,of the Rheinland TechnicalInspection Agency (TUV), has written a paperdescribing a series of tests which the agency performsto qualify PLCs for safety-relevant applications.However, the paper is badly translated and it isdifficult read with any real understanding. Furtherinvestigations have uncovered a few more facts aboutTUV and its PLC qualification program. TUV is anindependent organization that works closely with theGerman government. The organization certifies

systems for use in safety applications (i.e., railroad,aircraft, nuclear, petrochemical industries). TUV hasdifferent classes of certification, and the Germangovernment requires a specific class of TUVcertification for these safety applications. Theorganization is divided into various companies thatappear to be named after the geographical location theyservice. TUV-Rheinland is developing a series ofcertification tests for PLCs. In addition, certain PLCmanufacturers, actively selling their systems in safetyapplication, are pursuing TUV-Rhienland certificationof those PLC systems they expect to be used inGerman safety applications.

6.6. PLC Software Bug

Following is the text of a memorandum that wasdistributed when a software error was found in a PLCsoftware product. The software manufacturer isreferred to as SM, the PLC manufacturer is referred toas PM, and all names and phone numbers aresuppressed in the copied version below:

A Bug in SM PLC Software (Version X.X) Can Cause Erratic and Unsafe Equipment Operation

TttIS IS AN IMPORTANT SAFETY ISSUE-PLEASE ACT PROMPTLY!

Required Action:

If you are using a PM programmable controller and have programmed it with the SM programmable logiccontroller (PLC) using Version X.X software, please immediately reload your system using SM's latestsoftware release: Version XX. SM will supply you with the upgraded software at no charge.

The local sales representative for the software is name at distributor, phone number. For further informationabout this, please contact name, phone number, or name at SM, phone number.

The Problem:

SM contacted company to inform us that there is a problem in the Version XX programming software fortheir Programmable Logic Controller. A bug in their product can corrupt a controller's logic and causeequipment to operate erratically. IF your controller operates such safety-related equipment as a laser shutteror an access door, this unpredictably erratic behavior can cause potentially hazardous safety problems.

Your cooperation is appreciated.

Name

Title, phone number

NUREG/CR-6090 76

Appendix B

The problem that required urgent attention was asimple programming error. The programmer of thePLC software tool had failed to reset a pointer, and thepointer was vital to operation of the PLC upondownloading the new application software.

6.7. PLC Safety Concerns

To give the reader an idea of what level of redundancyand availability is needed to reach the safety levelsrequired by industry, the example below is presented.It is assumed that the plant requires a hazard rate of 1failure every 3000 years-a common requirement inthe chemical, oil, or nuclear power industries.

The MTBF for the system failing dangerously wasused to calculate unavailability. Markov models were

used to calculate the MTBF for system failures(Frederickson 1990; Frederickson and Beckman 1991;Triconex 1990). Both the MTBFs of safe failures anddangerous failures were calculated. Safe failures arefailures of the ESD system that cause the ESD systemto place one or more field devices in a safe state. Thesafe state was taken as the de-energized state in theMarkov models. Dangerous failures are failures of theESD system that cause the ESD system to place one ormore field devices in a dangerous state. The dangerousstate was the energized state in the Markov models.For this example, the MTBF for dangerous failures willbe used. The MTBF for safe failures is not consideredsince these failures do not create a hazard.

The MTBFs for dangerous failures for various PLCsystems are listed in Table 1 below (Fredrickson 1990).

Table 1. Dangerous Failure MTBF of Various PLC Systems.

PLC SYSTEM Dual PLC Dual PLC Triple PLC Triple PLC TMR PLCSingle 1/0 Dual 110 Single I/O Dual 1/0

MTBF 4.31 25.54 5.07 60.8 18,745DANGEROUS(years)

Table 1 assumes the following numbers:

MTRO = 0.5 hrs. An average of 0.5 hours is requiredto bring a piece of equipment back on-line.

MTRF = 1.0 hrs. The component is assumed to bereceived from stock within one hour.

MTDL = 2.5 hrs. The maintenance personnel requirean average 2.5 hours to locate the fault. This includesthe time from the initial detection of the fault, findingthe correct solution, and waiting for a new part.

Totalling these figures yields a mean time to repair of

The mean time to diagnose the presence of a systemfault, MTDF, is related to the average time betweensystem tests. If system test are completed weekly thenthe MTDF is 84 hours (assuming random failures mayoccur at anytime during the week) giving an MDT of88.0 hrs.

The availability, A, (considering dangerous failuresonly) for each PLC system is calculated by

A = MTBF / (MTBF + MNT).

The results are shown in Table 2.

MT'R = 4.0 hrs.

77 NUREG/CR-6090

Appendix B

Table 2. Availability of Various PLC Systems.

PLC SYSTEM Dual PLC Dual PLC Triple PLC Triple PLC TMR PLCSingle 110 Dual 1/0 Single I/O Dual 1/0

AVAILABILITY (%) 99.76746 99.96068 99.80225 99.98348 99.99995

Table 2 assumes the demand rate, D, of the ESDsystem is 3 demands per year, or

D = 3.425 x 10-4 demands/hour.Now, the hazard rate, H, is calculated fromH=DxUwhere

U=I-A.

Table 3 shows the hazard rates for each system.

Table 3. Hazard Rate of Various PLC Systems.

PLC SYSTEM Dual PLC Dual PLC Triple PLC Triple PLC TMR PLCSingle 1/0 Dual 1/0 Single 1/0 Dual 110

HAZARD RATE 20.93 3.54 17.80 1.49 0.0048(hazards/3000 yrs.)

As the above exercise illustrates, only one systemmeets the requirement desired, and that is a triplemodule redundant (TMR) PLC system. The TMRsystem is nearly three orders of magnitude safer thanall other PLC systems. It is important to haveredundant CPU modules, but the effect of redundant1/0 modules is significant. From single to dual I/Omodules nearly an order of magnitude of safety isgained.

The analysis here was completed for the PLC systemonly. The ESD project should perform a similaranalysis for the entire ESD system, including the PLC,software, and field devices.

The amount of automatic testing on the system has asignificant effect on down time, which can affect thehazard rate. Thus, the automatic testing of the systemcan be increased from weekly to daily and the hazardrates in Table 3 would improve. The amount ofautomatic testing to use is a trade-off betweenpersonnel effort and the desired safety level. Theperiod between automatic testing can be made aninsignificant factor in the safety equation if good

preliminary calculations are made and the appropriatesystem is chosen.

Using the example calculations above, it appears asingle TMR PLC system can meet the needs of thenuclear power industry. It is not clear, however, thatthe TMR system meets all other regulations andguidance of the NRC.

One issue to consider is the single-failure criterion(IEEE-279). Most TMR systems use identicalhardware and software modules, thus openingthemselves up to common-mode failures. Certaincommon-mode failures can fall within the scope of thesingle-failure criterion, thus requiring two TMRsystems.

With quadruply redundant and completely independentsafety systems, a single PLC with single 1/0 for eachquadrant should suffice. Of course, the appropriatecalculations should be provided to verify thisassumption.

NUREGICR-6090 78

Appendix B

7. REMARKSThe life cycle of the ESD system must have a wellthought out plan, and the plan must be flexible enoughto allow changes without relaxing the safetyrequirements. The safety of the ESD system must beanalyzed throughout the life of the system. It is notenough to analyze the safety of the system one timeafter the design is complete, because many changes tothe system will occur after the completion of thedesign. Thus, it is important to verify the safety of thesystem after each change. It is also helpful to initiatesafety audits that re-analyze the entire system atperiodic intervals.

Documentation is very important. Good documentationof decisions and the reasons for the decisions, recordedthroughout the life of the system, can reduce thenumber of errors introduced into the system. Theproject mangers must provide the necessary people orallow the necessary time to produce good documents.The documentation of the project will be invaluablewhen troubleshooting, understanding problems,training personnel, and aiding in avoidance andanalysis of plant accidents.

Programmable PLC systems used in safety applicationshave many of the same issues and vulnerabilities asother software-based systems. Careful consideration ofthe use of standard methods of software review forPLC safety systems should be made. If such methodsare applicable, then these methods should be, embracedby the PLC community. It may be possible to identify asubset of those methods that would apply to PLCsspecifically, but it would have to be shown that thesubset was complete in the sense that the methodswhich were outside the subset did not apply to PLCsoftware.

79 79 NUREGICR-6090

Appendix B

References

Adamski, Robert S., 1991, "Evolution of Protective Systems in the Petro-Chemical Industry," Instrument Societyof America (ISA) Transactions--Control Systems Safety, Vol. 30, No. 1.

Balls, Basil W., and Cole, Simon R., "Design Principles for Safety Systems," Instrument Society of America(ISA) Transactions-Control Systems Safety, Vol. 30, No. 1, 1991a.

Balls, Basil W., and Gruhn Paul, "Design Considerations for High-Risk Safety Systems," Instrument Society ofAmerica (ISA) Transactions-Control Systems Safety, Vol. 30, No. 1, 1991b.

Banks, William W. Jr., and Wood, Charles Cresson, "Human Error: A Major Consideration in Systems Security,"Lawrence Livermore National Laboratory, Document Number UCRL-JC-108922, Livermore, California,November 25, 1991.

Barter, Robert, and Zucconi, Lin, "Verification and Validation Techniques and Auditing Criteria for CriticalSystem-Control Software," Livermore Lawrence National Laboratory, Livermore, California, September1993.

Bongarra, James P. Jr, VanCott, Harold P., Pain, Richard F., Peterson, L. Rolf, and Wallace, Ronald I., "HumanFactors Design Guidelines for Maintainability of Department of Energy Nuclear Facilities," LawrenceLivermore National Laboratory, Document Number UCRL-15673, Livermore, California, June 18, 1985.

Bowman, William C., Archinoff, Glenn H., Raina, Vijay M., Tremaine, David R., and Leveson, Nancy G., "AnApplication of Fault Tree Analysis to Safety Critical Software at Ontario Hydro," Ontario Hydro, Toronto,Ontario, Canada, M5G 1X6, no date.

Bryant, J.A., "Design of Fail-Safe Control Systems," Power, January, 1976.DOD, See U.S. Department of Defense.EPRI, Procedures for Treating Common Cause Failures in Safety and Reliability Studies, Volume I-Procedural

Framework and Examples, and Volume 2-Analytic Background and Techniques, EPRI NP-5613, 1988.Fisher, Thomas G., "Are Programmable Controllers Suitable for Emergency Shutdown Systems?" Instrument

Society of America (ISA) Transactions-Programmable Controllers, Vol. 29, No. 2, 1990.Frederickson, A. Anton, "Fault Tolerant Programmable Controllers for Safety Systems," Instrument Society of

America (ISA) Transactions, Vol. 29, No. 2, 1990.Frederickson, Tony, and Beckman, Lawrence V., "Comparison of Fault Tolerant Controllers Used in Safety

Applications," Instrument Society of America (ISA) Transactions--Control Systems Safety, Vol. 30, No. 1,1991.

Gruhm Paul, "The Pros and Cons of Qualitative & Quantitative Analysis of Safety Systems," Instrument Society ofAmerica (ISA) Transactions-Control Systems Safety, Vol. 30, No. 1, 1991.

Hamacher, Carl V., Vranesic, Zvonko G., and Zaky, Safwat G., Computer Organization, 3rd ed., McGraw-Hill,New York, NY, 1990.

Hamming, R. W., Coding and Information Theory, 2nd ed., Prentice-Hall, Englewood Cliffs, NJ, 1986.Health and Safety Executive, "Programmable Electronic Systems in Safety Related Applications: Part 1-An

Introductory Guide," Library and Information Services, Broad Lane, Sheffield S3 7HQ, United Kingdom,1987.

Heron, RIL., "Critical Fault Control System," Presented at Florida Municipal Utilities Association 21st AnnualEngineering & Operations Workshop, Ft. Pierce, Florida, November 4-6, 1986.

HM Nuclear Installations Inspectorate, "Windscale Vitrification Plant Shield Door Incident 15 September 1991,"London: HMSO, 1991.

Hughes, Thomas A., Programmable Controllers, Research Triangle Park, North Carolina: Instrument Society ofAmerica, 1989.

Humphrey, Watts S., Managing the Software Process, Menlo Park, California: Addison-Wesley PublishingCompany, Inc., 1989.

81 NUREG/CR-6090

Appendix B

Ichiyen, N., Clark, A.B., Joannou, P.K., Harauz, J., and Tremaine, D.R., "The Canadian Nuclear Industry'sInitiative in Real-Time Software Engineering."

IEC, See International Electrotechnical Commission.IEEE, See Institute of Electrical and Electronics Engineers.Institute of Electrical and Electronics Engineers Inc., 345 East 47th Street, New York, NY.

IEEE-1042, "IEEE Guide to Software Configuration Management," September 1987.IEEE-1058.1, "IEEE Standard for Software Project Management Plans," December 1987.IEEE-279, "Criteria for Protection Systems for Nuclear Power Generating Stations," 1971.IEEE-352, "IEEE Guide for General Principles of Reliability Analysis of Nuclear Power Generating Station

Safety Systems," 1987.IEEE-610.12, "IEEE Standard Glossary of Software Engineering Terminology," February 1991.IEEE-828, "IEEE Standard for Software Configuration Management Plans," June 1983.IEEE1ANS P-7-4.3.2, "Standard Criteria for Digital Computers in Safety Systems of Nuclear Power Generating

Stations-Draft 4," June 1992.Instrument Society of America

ISA RP55.1, "Hardware Testing of Digital Process Computers," 1983.ISA SP84.02, "SP84 Programmable Electronic Systems for Use in Safety Applications, Annex K-System

Analysis," Draft 9A, July 1992.International Electrotechnical Commission, 3 Rue de Varembe, Geneve, Switzerland.

IEC-65A, "Software for Computers in the Application of Industrial Safety-Related Systems," August 1, 1991.IEC-848, "Graphcet," 1986.IEC-880, "Software for Computers in the Safety Systems of Nuclear Power Stations," 1986.

Inverso, Dennis A., "Document for Programmable Electronics Systems: Safety Considerations in Documentationfor BPCS and ESDs," Instrument Society of America (ISA), Paper #91-0333, 1991.

ISA, See Instrument Society of America..Keskar, P.Y., "Structured Approach in PLC Programming for Water/Waste Water Applications," Instrument

Society of America (ISA) Transactions, Vol. 29, No. 2, 1990.Lawrence, Dennis, "Software Reliability and Safety in Nuclear Reactor Protection Systems," Livermore Lawrence

National Laboratory, Livermore, California, June 1993.Leveson, Nancy G., and Harvey, Peter R., "Analyzing Software Safety," IEEE Transactions on Software

Engineering, Vol. Se-9, No. 5, September 1983.Leveson, Nancy G., Cha, Stephen S., and Shimeall, Timothy J., "Safety Verification of ADA Programs Using

Software Fault Trees," IEEE Software, July 1991.Magison, E.C., "Make Sure Your.System is Safe," Instrument & Control Systems (I&CS), December, 1979.

MIL-STD, See U.S. Department of Defense.Musa, J., lannino, A., and Okumoto K., Engineering and Managing Software with Reliability Measures, New

York, NY: McGraw-Hill, 1987.Ontario Hydro and Atomic Energy of Canada, Ltd., "Procedure for Systematic Design Verification of Safety

Critical Software-Draft," Ontario Hydro, Toronto, Ontario, Canada, February 28,1992.Paques, Joseph-Jean, "Basic Safety Rules for Using Programmable Controllers," Instrument Society of America

(ISA) Transactions, Vol. 29, No. 2, 1990.Paques, Joseph-Jean, "The Elements of Safety for Using Programmable Controllers," Instrument Society of

America (ISA) Transactions-Control Systems Safety, Vol. 30, No. 1, 1991.Parnas, D. L., "Proposed Standard for Software for Computers in the Safety Systems of Nuclear Power Stations

(based on IEC Standard 880)," TRIO, Computing and Information Science, Kingston, Ontario, March 26,1991.

Patterson, David A., and Hennessy, John L., Computer Architecture-A Quantitative Approach, 1st ed., MorganKaufmann Publishers, San Mateo, CA, 1990.

NUREG/CR-6090 882

Appendix B

Pilsworth, R., "Software Standards for Defense Procurement," Institute of Electrical and Electronics Engineers,Inc., 345 East 47th Street, New York, NY, 1988.

Pofahl, Ekkehard, "The TUV Test Procedure for Programmable Logic Controllers," Dipl.-Phys., TUV Rheinland,Cologne, West Germany, Rheinland Technical Inspection Agency.

Preckshot, G.G., "Data Communications Systems in Nuclear Power Plants," UCRL-ID-1 14564, LawrenceLivermore National Laboratory, Livermore, California, May 1993a.

Preckshot, G.G., "Data Communications," UCRL-ID-l 14567, Lawrence Livermore National Laboratory,Livermore, California, May 1993b.

Preckshot, G.G., "Real-Time Performance," UCRL-ID-1 12616, Lawrence Livermore National Laboratory,Livermore, California, May 1993c.

Rondeau, Dan M., and Blackledge, Michael A., "The Preferred Process: Software Development," DocumentNumber SAND90-2227/7, Sandia National Laboratories, Albuquerque, New Mexico, 1991.

Sandia National Laboratories, Albuquerque, New Mexico."Sandia Software Guidelines Volume 3: Standards, Practices, and Conventions," Document Number SAND85-

2346, 1986."Sandia Software Guidelines Volume 1: Software Quality Planning," Document Number SAND85-2344,

1987a."Sandia Software Guidelines Volume 5: Tools, Techniques, and Methodologies," Document Number SAND85-

2348, 1987b.Saudi Aramco Material Specification, "Programmable Controller Based ESD Systems--Draft Issue," Number 34-

AMSS-623, September 1990.Shooman, M. L., Software Engineering: Design, Reliability, and Management, New York, N-Y: McGraw-Hill,

1983.Smith, Michael W., "PLC Emergency Shutdown Systems Used with a DCS in a Pilot Plant Environment,"

Instrument Society of America (ISA), Paper #91-0599, 1991.Smith, Steven E., "Fault Coverage in Plant Protection Systems," Instrument Society of America (ISA)

Transactions-Control Systems Safety, Vol. 30, No. 1, 1991.Sparkman, D., "Techniques and Processes in Software Safety and Reliability: Part One," Version 2.0, Lawrence

Livermore National Laboratory, Nuclear System Safety Program, February 7, 1992.Spiker, Rolf, "Are All Emergency Shut-Down Technologies Safe Enough?" Preliminary, Industrial Automation

Inc., Houston, Texas, October 1990.Triconex Corporation, "Tricon Fault-Tolerant Control: Technical Product Guide," Irvine, CA, 1990.U.S. Department of Defense

DOD 2167A, "Defense System Software Development," ,February, 1988.MIL-STD-483A, "Configuration Management Practices for Systems, Equipment, Munitions, and Computer

Programs," September 11, 1989.MIL-STD-499A, "Engineering Management," May 1, 1974.MIL-STD-1456A, "Configuration Management Plan," Department of the Air Force, June 4, 1985.MIL-STD-1521B, "Technical Reviews and Audits for Systems, Equipment, and Computer Software,"

Department of the Air Force, June 4, 1985.Vora, Deepak D., "Engineering Contractor's Perspective on Programmable Logic Controller," Instrument Society

of America (ISA), Paper #91-0531, 1991.Walczak, Thomas A., "Emergency PLC Controlled Shutdown," Instrument Society of America (ISA), Paper #90-

609, 1990.Wilhelm, RE. Jr., Programmable Controller Handbook, New York, NY: Hayden, 1985.

83 NUREG/CR-6090

NRC FORM 335 U.S. NUCLEAR REGULATORY COMMISSION 1. REPORT NUMBER(2-89) (Assigned by NRC. Add VoI., SupIp., Rev.,NRCM 1102, and Addendum Numbers, If any.)3201,3202 BIBLIOGRAPHIC DATA SHEET NUREG/CR-6090

(See instructions on the reverse) UCRL-ID-112900

2. TITLE AND SUBTITLE

The Programmable Logic Controller and Its Application 3. DATE REPORT PUBLISHED

in Nuclear Reactor Systems MONTH YEAR

September 19934. FIN OR GRANT NUMBER

L1867

5. AUTHOR(S) 6. TYPE OF REPORT

J. Palomar, R. Wyman Technical7. PERIOD COVERED (inclusive Dares)

8. PERFORMING ORGANIZATION - NAME AND ADDRESS 1fiNRC, provide Division, Office or Region, U.S. Nuclear Regulatory Commission. and mailing address; if contractor, providename and mailing address.)

Lawrence Livermore National LaboratoryP.O. Box 808Livermore, CA 94550

9. SPONSOR ING ORGANIZATION - NAME AND ADDRESS (if NRC. type "Same as above"' if contractor, provide NRC Division, Office or Region, U.S. Nuclear Regulatory Commission,

and mailing address)

Division of Reactor Controls and Human FactorsOffice of Nuclear Reactor RegulationU.S. Nuclear Regulatory CommissionWashington, DC 20555-0001

10. SUPPLEMENTARY NOTES

11. ABSTRACT (200 words or less)

This document provides recommendations to guide reviewers in the application ofProgrammable Logic Controllers (PLCs) to the control, monitoring and protection of nuclearreactors. The first topics addressed are system-level design issues, specifically including safety.The document then discusses concerns about the PLC manufacturing organization'and theprotection system engineering organization. Supplementing this document are two appendices.Appendix A summarizes PLC characteristics. Specifically addressed are those characteristics thatmake the PLC more suitable for emergency shutdown systems than other electrical/electronic-based systems, as well as characteristics that improve reliability of a system. Also covered arePLC characteristics that may create an unsafe operating environmenL Appendix B provides anoverview of the use of programmable logic controllers in emergency shutdown systems. Theintent is to familiarize the reader with the design, development, test, and maintenance phases ofapplying a PLC to an ESD system. Each phase is described in detail and information pertinent tothe application of a PLC is pointed out.

12. KEY WORDS/DESCR!PTORS (List words or phrases that will assist researchers In locating the report.) 13. AVAILABILITY STATEMENT

PLC (Programmable Logic Controller) UnlimitedEmergency Shutdown Systems 14. SECURITY CLASSIFICATION

Safety Systems (This Pege)

Programmable Electronic Systems UnclassifiedConfigurable Systems (This Reportt

Unclassified15. NUMBER OF PAGES

16. PRICE

NRC FORM 335 (2-89)

Federal Recycling Program

The Programmable Logic · This document provides recommendations to guide reviewers in the...

Documents

Transcript of The Programmable Logic · This document provides recommendations to guide reviewers in the...