ML063530433

From kanterella
Jump to navigation Jump to search

Protection System Digital Replacement Project: Technical Discussions for Selected Safety System Topics
ML063530433
Person / Time
Site: Oconee  Duke Energy icon.png
Issue date: 12/13/2006
From: Burzynski M
AREVA NP
To:
Office of Nuclear Reactor Regulation
References
Download: ML063530433 (86)


Text

Oconee PlantProtectionSystem DigitalReplacement Project:

Technical Discussions for Selected Safety System Topics Mark Burzynski Sean Kelley Dr. Steffen Richter 1 AREVA NP Inc > NRC Meeting - December 13, 2006 1

Introduction Mark Burzynski 2

2 AREVA NP Inc >> NRC Meeting -- December NRC Meeting 13, 2006 December 13, 2006 2

Meeting Objectives

> Provide an overview of the Oconee digital plant protection system

> Provide technical discussion of key elements of the Oconee digital plant protection system (PPS)

> Provide detailed technical discussion of key aspects of the TELEPERM XSTM regarding communication independence 3

AREVA NP Inc I > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 3 L

Meeting Outline

" Introduction and Background (Mark Burzynski)

> Oconee System Overview (Sean Kelley)

> Communication Networks and Isolation Schemes (Sean Kelley)

" Communication Processing (Dr. Steffen Richter)

" Interchannel Communication (Sean Kelley)

> Communication with Service Unit (Dr. Steffen Richter)

> Communication via Gateway (Dr. Steffen Richter)

> Regulatory Analysis (Robert Gill) 4 AREVA > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 4

Introduction

> TXS computer processors use a deterministic operating system

  • Increases the predictability of the software

> The most important features of the TXS software design include a strictly cyclic processing of application software

  • Asynchronous operating system (meaning no real-time clock that redundant processors synchronize to) reduces failure potential and enhances reliability

> Only static memory allocation is used

  • Each variable in the application program has a permanent dedicated place in memory, so that memory conflicts caused by dynamic memory allocation are not possible

> There is a complete absence of process-driven interrupts

" Other important features include:

  • Bus systems with a constant load

" No long-term data storage

" No use of external data storage media.

Potentialfor software failure is minimized by deterministic operatingsystem built high-quality software design tools AREVA > NRC Meeting - December 13, 2006 5

Background

> The TELEPERM XS system is fully described in Topical Report EMF-2110, Revision 1, "TELEPERM XS: A Digital Reactor Protection System," September 1, 1999

> NRC issued a safety evaluation report for the topical report Letter dated May 5, 2000, from Stuart A. Richards, NRC, to Jim Mallay, Siemens Power Corporation, 'Acceptance for Referencing of Licensing Topical Report EMF-2110 (NP), Revision 1, "TELEPERM XS: A Digital Reactor Protection System" 6

Meeting -- December NRC Meeting 13, 2006 December 13, i AREVA NP Inc

> NRC

> 2006 6

Background

> The safety evaluation report concluded that "The design principle for software of Class IE systems is to ensure that the sequence of processing executed for each expected situation can be deterministicallyestablished. It discourages the use of non-deterministicdata, communications, non-deterministiccomputations, multitasking, dynamic scheduling, use of non-deterministic interruptsand event driven designs. Based on its review, the staff determines that the design of the TXS system satisfies this design principle for Class 1 E system software."

"The staff's conclusions are based upon the requirements of ANSI/IEEE-603 with respect to the design of the TXS system.

Therefore, the staff finds that the TXS system satisfies the requirementof 10 CFR 50.55a(h) with regard to ANSI/IEEE-603."

Presentationtoday will review the TXS communication independence features regardingcompliance with IEEE 603 - 1991 and applicableregulatoryguidance 7

AREVA > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 7

Oconee ProtectionSystem and TELEPERM XSTMOverview Sean Kelley 8RnV> NRC Meeting - December 13, 2006 8

Oconee PPS Architecture

~~Inputs .

TXS ' TXS TXS TXS Inpus RPS! RPS RPSI RPS Channel Control Board TXS ESe A SF SeI S D Alarms Gateway To St DlAnnunciators QAG TXS All equipment is located in

"- the Oconee Mi control room Converter Ethernet Switch Service Unit TXS, TXS, IXS *TXS n~y~t~c SF I5 tt Status Electric Voter I Voter I Odd ve SINEC-HI data lirn Odd Even;; __ Fiber optic SINEC-H 1 data lirk r _ _ L_ Fiber optic(Safety Related)

SINEC-L2 data link Network Architecture of the New Oconee PPS mRV Nn > NRC Meeting - December 13, 2006 9

Oconee PPS Architecture ESFAS ESFAS ESFAS RPS RPS RPS RPS Inputs Inputs Inputs Inputs Inputs Inputs Inputs Channel Channel Channel Channel Channel Channel Channel C

ESF Outputs ESF Outputs Fiberoptic Odd Channels Even Channels SINEC - L2data link Oconee PPS Interchannel Communication Architecture I AREVA NP Inc Ik

> NRC Meeting - December 13, 2006 10

r TELLayered EPERM XSTM System Software StructurePlatform on a Processing Architecture Module DevelopeI Application software Function diagram modules

>O* plant-specific I&C functions hardware-independent System software Function block library Generic interface I

V ITELEPERM XSTM runtime environment I I

  • plant-independent Operating system software and services
  • pre-developed (MICROS, MicroNET)

" qualified for safety applications I I Hardware-specific software I i architect 11 AREVA NP Inc L > NRC 13, 2006 December 13, Meeting - December NRC Meeting 2006 11

RTE ConfigurationModule

> "Generic interface" between I&C application and system software

> Generated by the SPACE code generator individually for each CPU

> Comprises parameters for RTE and various data structures/arrays needed to describe:

" a unique processor ID (CPU ID) for the processing module

" the operating and communication cycle times

" the entry points and interface data to the FDG modules to be processed

" all configuration data for the input/output (1/0) drivers

" the complete lists of all messages to be sent or received by the RTE and communication channel parameters 12 I AREVA NP Inc I L > NRC

> Meeting - December NRC Meeting - 13, 2006 December 13, 2006 12

Role of Runtime Environment

> Unified software environment for the processing modules used for the execution of the TXS application software (FDG modules)

> Hides all target system specifics from the FDG modules (hardware, operating system, communication media and protocols, I/O modules, etc.)

> Central control instance for

  • Cyclic processing of the FDG modules
  • Signal transfers via messages or directly by 1/0 modules

> Provides the interface of the system software with the TXS Service Unit for monitoring and servicing Tracing signal data, reading error messages, switching operation modes, adjusting parameterization of FB modules 13 AREVA NP Inc > NRC

> December 13, Meeting -- December NRC Meeting 2006 13, 2006 13

TXS Safety Classified Communication:

ProcessingOverview Application Software

- Level SVE2 Runtime Environment Communication Interface

- - P- Control Flow Data Flow SL21 To Optical Network 14

> NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 14 I AREVA NP Inc IL

TXS Safety Classified Communication:

ProcessingOverview

> Central Control Unit coordinates data flow in a sequential fashion:

1) Communication interface transfers messages from "receive RAM" to corresponding message input buffers
2) CRC checksum, message identification and sequence increment checks performed and transfer of messages from message input buffers to input function
3) Input function identifies individual signals within messages and allocates them to signal memories 15 AREVA NP Inc > Meeting -- December

> NRC Meeting 13, 2006 December 13, 2006 15

TXS Safety Classified Communication:

ProcessingOverview

4) Function diagram processing (including signal validation) is performed. Results stored in dedicated signal memory locations
5) Output function collects result signals and forms output messages.
6) RTE attaches new CRC checksum, message identification and cycle counter and stores messages in message output buffers
7) Communication interface transfers messages from message output buffers to "send RAM" 16 I AREVA NP Inc I L > NRC

> December 13, Meeting -- December NRC Meeting 2006 13, 2006 16

TXS Safety Classified Communication:

ProcessingSummary

> Runtime environment controls all processing actions and ensures discrete, cyclic processing

> Independent control flow of function computer and communication module

> Token passing protocol used at communication module level to avoid data collisions

> Individual memory locations for each message ensure separation of send and receive flows

> Checks performed on received messages (prior to function diagram processing) ensure valid message transmission

> Checks on input signals ensure valid input data to function diagrams System design ensures interference-free communication 17 I AREVA NP Inc I L > NRC

> NRC Meeting Meeting -

December 13, December 2006 13, 2006 17

TELEPERM XSTM Communication Networks and Isolation Schemes Sean Kelley 18 AREVA > NRC

> Meeting -- August NRC Meeting 31, 2006 August 31, 2006 18

TXS Safety Classified Communication:

Network Configurations Communications between safety function channels or between different cabinets in the same safety function channels use fiber optic cabling and optical link modules TXS platform provides multiple options for reliable network configurations Configurations selected based on specific applications Selected network configurations ensure high network reliability 19 AREVA NP Inc I > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 19

TELEPERM XSTM Communication Types of Communication Buses TXS backplane bus (K32)

  • 32 bit parallel bus in the TXS sub-rack Communication

... inside TXS computer

  • Up to 8 communicating CPUs (SVE or SCP) units
  • Maximum data package size is 8192 bytes TXS PROFIBUS (L2) network
  • 1.5 Mbit/sec optical (RS422) token bus ... between -XS computer
  • Maximum data package size is 244 bytes units TXS Ethernet (H1) network
  • 10 Mbit/sec optical bus, CSMA/CD according to IEEE 802.3 ... with gateway
  • Point-to-point or switch connections and Service Unit
  • Maximum data package size is 1536 bytes 20

I REVA NP Inc > NRC

> December 13, Meeting -- December NRC Meeting 2006 13, 2006 20

.SVE2 + TXS PROFIBUS (L2) module SL21 21 AREVA NP Inc I > Meeting -- December NRC Meeting

> NRC 13, 2006 December 13, 2006 21 L

TXS Safety Classified Communication:

Optical Link Modules

> Each link module contains electrical and optical channels

  • Only optical channels are used for safety related connections between different cabinets or divisions

> Link modules actively monitor optical paths for interruption Monitoring achieved through "echo" functions Faults in link modules or in optical paths are indicated locally and signaled to cabinet monitoring modules 22 AREVA NP Inc I > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 22 L

Communication Independence Communications Isolation Communications Isolation

/Buffer Circuit*

Safety Function A Fiber Optic Cable Safety Function B ES/RPS - Communication between safety channels and with MSI (Two-way communication)

Oconee Communication Isolation Design 23 I AREVA NP Inc IL

>> NRC NRC 13, 2006 December 13, Meeting -- December Meeting 2006 23

IEEE 7-4,3,2 Communication Independence Safety Function A Safety Function B Figure G2-Communication between safety channels (Two-way communication)

IEEE Standard 7-4.3.2 Annex G Communication Isolation Guidance 24 AREVA > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 24

TEL EPERM XSTM Communication Processing Dr. Steffen Richter 25 AREVA NP Inc I > NRC

> Meeting -- August NRC Meeting 31, 2006 August 31, 2006 25 L

0 TELEPERM XSTM Communication Basic Principle

> Communication protocol does not use acknowledges by the receiver

  • Deterministically excluded that the receiver of a message can have any influence on the sender's operation

> Likewise, the sender cannot influence the operation of the receiver

  • Receiver can only act on the data in accordance with the function application software 26 Meeting -- December NRC Meeting 13, 2006 December 13, I AREVA NP Inc IL

> NRC

> 2006 26

A EVA OperatingPrinciples

> Strictly cyclic signal processing

> No synchronization between processing modules (CPUs)

> Cyclic data transfer via network connections

  • Predefined package size
  • Constant bus load
  • Checksum and message age monitoring

> No dynamic allocation of resources

> Program code executed from Flash EPROM

> Parameter data stored in RAM and EEPROM (power-fail safe)

> Simple type of multi-tasking to handle background activities

" Cyclic self-test

" Response to service commands from Service Unit AREVA NP Inc > NRC Meeting - December 13, 2006 27

TELEPERM XSTM Operation Strictly Cyclic Processing 9

I AREVA NP Inc I

> NRC Meeting - December 13, 2006 28

Cyclic Signal Processing 29 AREVA NP Inc I k, > NRC

> NRC Meeting Meeting -

- December 13, 2006 December 13, 2006 29

Interference-free Communication between TXS Units Characteristics

> Application of a fiber optic transmission medium

  • Effects caused by electromagnetic interference cannot propagate

> Individual DPRAM buffers for each message

  • Separation of the data flow for sending and receiving

" Cyclic processing of all application and communication functions, including message transmission

  • Avoidance of mechanisms influencing the linked communication systems, independent control flow of communication modules and processing modules

> Check on all received messages

  • Message authentication, validity check and message age monitoring

> Not-a-number checking on all analog data received through data messages

  • Prevention of float exception due to input data

> On-line validation of input data in the TXS application software

  • Limits the propagation of faulty data

" Provides valid input data for the subsequent function diagram module processing 30 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 30

TXS PROFIBUSCommunication Module SL21

> SL21 modules transfer data without influencing the message data.

> Sender side:

  • Performs an automatic polling cycle on message buffers of the DPRAM to recognize that new messages are stored there In parallel, it waits for receiving the token (according to the token passing principle)

Reception of token equals permission to put data on the bus After sending messages (if some), token is forwarded to the next SL21 on the bus (round robin)

> Receiver side:

  • Listens to the bus, receives data messages addressed to it

" Directs messages to specific DPRAM message buffers (predefined service access points serve for addressing buffer #)

31 Meeting -- December NRC Meeting 13, 2006 December 13, I AREVA NP Inc IL I > NRC

> 2006 31

Message Transfer

> Logical point-to-point connections

" Separate logical MicroNET communication channel for each message (point-to-point)

" Designed fixed size of each message

" Unique MicroNET communication interface independent of type of buses

> Strictly cyclic message transfer

  • Designed single communication cycle time Tcom for the system (For Oconee: 25 msec)

> Standard message frame

" Standard header (sender ID, receiver ID, message type, size, cycle count, CRC checksum, ... )

  • Designed fixed size data section Message size determined individually for each message by SPACE code generator 32 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 32

Unified RTE Message Header 33 I AREVA NP Inc I

> NRC

> 13, 2006 December 13, Meeting -- December NRC Meeting 2006 33

Message Framing AREVA NP Inc > NRC Meeting - December 13, 2006 34

TELEPERM XSTM Communication Method mRV> NRC Meeting - December 13, 2006 35

Data Message Transfer via L2 Bus 36 I AREVA NP Inc I iL> NRC

> Meeting - December NR Meeting - 13, 2006 December 13, 2006 36

Input Checks of Messages RTE cycle phase 2

> The integrity of all messages received from other processing modules is checked in phase 2 of the RTE cycle by:

" Message length and CRC checksum for the occurrence of individual bit errors

" Message ID, type, sender CPU ID, and receiver (i.e., own) CPU ID to ensure the message is the expected one

  • Sequence number increment to ensure that a new message has been received (message age monitoring)
  • Message status to make sure the message was marked valid by the sender (i.e., sender CPU not in diagnosis mode) 37 I AREVA NP Inc I L > NRC

> Meeting - December NRC Meeting - 13, 2006 December 13, 2006 37

Message Age Monitoring Message age monitoring performed by RTE of receiving CPU Status is based on cycle count of sending CPU

" NEW o New message received and message age check passed

" ONEMISS o Single miss of message and previous message is used again

" INVALID:

o No valid message available and message buffer marked invalid 38 AREVA >

> Meeting -- December NRC Meeting NRC 13, 2006 December 13, 2006 38

Handling of Communication Errors Message Age Monitoring

  • Error situation: A data message cannot be received by the Runtime Environment (RTE) for two (or more) cycles
  • Signaling:
  • Fault indication at the application software level (binary signal via TXS function block RTE-Output)

Error message by the RTE sent to the service unit

> Handling of the message buffer:

  • Message marked invalid, subsequently ...
  • ... ERROR status flag set for all application data contained in the message In this way TXS function blocks used in the application software (FDG module) are able to identify and consider such data as faulty and exclude them from further processing by the application software 39 AREVA NP Inc >

> NRC NRC Meeting December 13, Meeting -- December 2006 13, 2006 39

TELEPERM XSTM InterchannelCommunication Sean Kelley 40 AREVA NP Inc L > NR

> 31, 2006 August 31, Meeting -- August NRC Meeting 2006 40

Interference-free Communication

> Use of fiber optic transmission medium

  • Effects caused by electromagnetic interference cannot propagate

> Individual DPRAM buffers for each message

  • Separation of the data flow for sending and receiving

> Cyclic processing of application and communication functions, including message transmission, without any possibilities of influencing linked communication systems

  • Independent control flow of communication module and processing module

> Check on the received messages to determine whether the transmission has been performed with valid message data

  • Message header and CRC checksum checks along with message age monitoring

> On-line validation of input data is applied in TXS application software

  • Limits propagation of faulty data
  • Provides valid input data for subsequent function diagram module processing 41 AREVA >

> Meeting -- December NRC Meeting NRC 13, 2006 December 13, 2006 41

InterchannelCommunication Architecture ESFAS ESFAS ESFAS RPS RPS RPS RPS Inputs Inputs Inputs Inputs Inputs Inputs Inputs Channel Channel Channel Channel Channel Channel Channel r,

Use of interchannel communication does not create new interfaces, it simply changes the location-of the interconnections ESF Outputs ESF Outputs E~U Fibereptic Odd Channels Even Channels SINEC- L2 datafink Oconee PPS Interchannel Communication Architecture AREVA NP Inc I > NRC Meeting - December 13, 2006 42 i

Advantages of InterchannelCommunications

> Comparison of like process parameters between different safety channels allows:

" Exclusion of faulty signals from trip logic (on-line validation)

" Automatic channel checks for analog signals, asynchronous detection for binary signals

" Reduction of spurious actuation

" Increased system availability (fault tolerance) 43 I

AREVA NP Inc > Meeting -- December NRC Meeting

> NRC 13, 2006 December 13, 2006 43

On-line Signal Validation

> On-line validation of redundant input data is performed using the 2nd min / 2nd max analog signal selection feature

" For trip functions looking for decreasing values, the 2nd min logic passes the second lowest value to comparator logic

" For trip functions looking for increasing values, the 2nd max logic passes the second highest value to the comparator logic

> Similar functionality using 2/4 and 2/3 function blocks for binary signals

> Alarm indication is initiated by these function blocks in order to signal early information about discrepancies between redundant input signals or failure in the I&C equipment

> If one or more of the redundant input data is marked with the ERROR status flag, it is excluded using error propagation barriers (i.e. 2.MIN, 2.MAX, 2/4, 2/3, etc. function blocks)

> On-line signal validation functions behave identically and independently of the origin of the detected invalid data and the remaining valid data 44 AREVA NP Inc I NRC

>> NRC Meeting -- December Meeting 13, 2006 December 13, 2006 44 L

On-line Signal Status Processing ErrorPropagationBarriers AREVA NP Inc I > NRC Meeting - December 13, 2006 45 I

On-line Analog Signal Processing No Fault Example AREVA NP Inc > NRC Meeting - December 13, 2006 46

On-line Analog Signal Processing FailureExample 47 I AREVA NP Inc I

> NRC

> 13, 2006 December 13, Meeting -- December NRC Meeting 2006 47

Spurious Actuation Prevention

> As compared to conventional analog designs, which would actuate one channel on any signal lower/higher than the comparator setpoint, the 2nd min / 2nd max logic compares redundant process data from all channels prior to the setpoint comparison.

> The result is that the process measurement nearest the trip setpoint will not result in an overly conservative spurious trip in any channel.

  • Failed signals do not result in partial trip condition

" Instead, all channels will trip correctly based on the remaining valid 2nd min/ 2nd max inputs.

48 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 48

IncreasedSystem Availability

> In conventional analog designs, a channel could fail to trip during a detected 2 out of 3 condition due to a hardware failure in the actuation path of the channel (for example Channel A trip relay)

> With 2nd min / 2nd max logic all channels use all available data in the setpoint comparison thereby ensuring that the overall function is performed correctly 49 AREVA NP Inc I > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 49 L

TXS FaultAccommodation:

rE FunctionalLogic AREVA ýp > NRC Meeting - December 13, 2006 50 I-C

Automated Channel Check Logic

> Currently channel checks are performed manually by operators every 12 hours1.388889e-4 days <br />0.00333 hours <br />1.984127e-5 weeks <br />4.566e-6 months <br /> by reading the individual signals and making a comparison

> 2.MIN and 2.MAX functionality can be used to automatically perform channel checks and alarm any process data that deviates from the other signals by a defined tolerance

> Data that deviates from the other inputs by more than the tolerance amount is alarmed but not excluded from the logic AREVA NP Inc > NRC Meeting - December 13, 2006 51 I

Interchannel Communication Summary

> In the PPS, like RPS/ESFAS input parameters undergo integrity and validity checks to determine whether the data is good prior to use

  • This prevents faulty data from being propagated throughout the channel

> Faulted data is removed from the measurement, thereby preventing spurious actuation and increasing system availability

  • NOTE: Data that deviates from the other inputs by more than a conservative amount is alarmed but not excluded from the logic

> Alarms are provided for both faulted and deviated data so operator action can be taken to investigate and correct the problem 52 AREVA NP Inc >> NRC Meeting -- December Meeting 13, 2006 December 13; 2006 52¸

TELEPERM XSTM Communication with Service Unit Dr. Steffen Richter 53 AREVA NP Inc > NRC

> Meeting -- August NRC Meeting 31, 2006 August 31, 2006 53

Oconee PPS Architecture TxS TXS TXS TXS IRnputs PSChannel Control Board TXS ESF ESF ESF E Alarms/ Gateway To setB SetC SetD *SetA Annunciators .AC L- TXS All equipment is located in M 1the Oconee d Icontrol room Converter L -

-- Ethernet Switch El Service Unit

[3nuo []m One way Data Flcw

~TXS TXS TXS TXS.0Oeaatic

ESF ESF Status Status Eectric Voter I VoterI Odd- Een SINEC-H1 data lirk Pen:- - Fiber optic SIN EC-H I data link Fiber optic(Safety Related)

SiNEC-L2 data link Network Architecture of the New Oconee PPS 54 I AREVA NP Inc I

> NRC

> 13, 2006 December 13, Meeting - December NRC Meeting- 2006 54

Role of MSI Computer 55 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 55

MSI as a Data Transmission Barrier AREVA NP Inc I > NRC Meeting - December 13, 2006 56

TELEPERM XSTM Service Unit Graphic Service Monitor Overview on CPUs of MIlTd/We11' X

the TXS I&C system Operating mode *ýý CPU R- Lcibs MO PRdundny R* I j... [ ... ...-

" Signalization, 0 s S niization, Single +ER-VA.ABO91 Loperation [oppara... F-no flag 0 0 alarms El 01122 Single +ER-VA.EB003 li1operation 1I3oppara... Fjno flag 0 0 El fl.132 VOM +VO.JB003 joperation [oppara... Ono flag 0 0 Selection/Execution .. 134 vOC +VO.JB043 Lýioperation lIToppara... noflag 0 0 of pre-defined i., 112 Single +ER-VA.JB003 Doperation loop para... '-no flag 0 0 02113 Single +ER-VA.JB091 'operation Mlop para... I-no flag 0 0 service actions J*LZI ...... . ... . , ..

1 i..ooou. _ ,o .__

  • Parametrization SHT server 1.06 / 2000-07-06 Database h etc. User waedt Privilege diag Client ID 2 2000-07-11 10:15:09 Menu-guided service actions El l-ask I File F

El A1.sm 2000-03-23 12:59:10 lAcknowledging 3114 Ackowld.event - A2.sm 2000-03-2119:13:33 3088

  • Tracing signals E-.Oevent old * *A3.sm 2000-03-21 19:13:36 3088 Performing tests

> NRC Meeting - December 13, 2006 57 I AREVA NP Inc Ik

TELEPERM XSTM Service Unit Dynamic Logic Viewer Function 58 AREVA NP Inc L > NRC

> 13, 2006 December 13, Meeting -- December NRC Meeting 2006 58

Graphic Service Monitor Custom Add-ons: Association to Binary FB Parameter Switch setting (binary parameter) fdVar = FD 1 FB 1 PARAM AREVA NP Inc > NRC Meeting - December 13, 2006 59 I

Access Control AREVA NP Inc > NRC Meeting - December 13, 2006 60

Example: Setting I&C ParametersOn-line Release Conditions N'

> R etn ec m e 3 066 AREVA NP Inc > NRC Meeting - December 13, 2006 61

Release Conditions 62 I AREVA NP Inc IL

> NRC 13, 2006 December 13, Meeting -- December NRC Meeting 2006 62

TEL EPERM XSTM Communication Types of Messages mRV> NRC Meeting - December 13, 2006 63

Message Transfers 64 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 64

Signaling Message Purpose and Content

" Assembled by RTE of each CPU

" In phase 6 of every cycle

> Consists of:

" Signaling message header

  • Status indication of the RTE (operation mode, status of release signals, flags indicating fault situations)

" Response to a service command handled before by the RTE (if some)

  • Any pending system error messages

" Any requested trace data 65 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 65

RTE Service Commands I AREVA NP Inc I

> NRC Meeting - December 13, 2006 66

RTE OperationModes mRV Pn > NRC Meeting - December 13, 2006 67

Input Check of RTE Service Commands 68 AREVA NP Inc L,> NRC

> - 13, 2006 December 13, Meeting - December NRC Meeting 2006 68

Communication with Service Unit 69 AREVA NP Inc >

> NRC Meeting -- December NRC Meeting 13, 2006 December 13, 2006 69 k

Coordinationof Tasks in a TXS CPU AREVA NP Inc > NRC Meeting - December 13, 2006 70

Task Activities in TELEPERM XSTM CPU AREVA NP Inc > NRC Meeting - December 13, 2006 71 k

RTE Service Commands 72 AREVA NP Inc iL> NRC

> NR Meeting Meeting -

13, 2006 December 13, December 2006 72

RTE Service Commands (cont) 73 I AREVA NP Inc IL NRC Meeting

> NRC

> 2006 13, 2006 December 13, Meeting -- December 73

RTE Service Commands (cont) 74 I AREVA NP Inc IL

> NRC

> 13, 2006 December 13, Meeting - December NRC Meeting- 2006 74

Communication with Service Unit

> Safety to Non-Safety Interface with Service Unit via MSI

> Physical Separation

> Electrical Isolation

> Access Controls for Location of TXS Equipment 75 AREVA NP Inc I L > NRC

> 13, 2006 December 13, Meeting -- December NRC Meeting 2006 75

TELEPERM XSTM Communication via Gateway Dr. Steffen Richter 76 AREVA NP Inc > NRC

> August 31, Meeting -- August NRC Meeting 2006 31, 2006 76

Oconee PPS Architecture RS/ RXS TS RS RInputs R S' R Channel Control Board TXS tSe B.Set QSF t Ch E Alarms/ Gateway To QA T

Set A S Annunciators 2 -* S _All equipment is located in M- the Oconee Lcontrol Media room Converter It Ethernet Switch Service Unit TXS TXS TXS TXS C0mmmm One way Data Ficm ESF ES Statu Status Io] Electric Voter I Voter I idd F,,iEDn rSINEC-HI1 data link A d .......---------

, Fiber optic SINEC-H1 data link r-____ __ Fiber optic(Safety Related)

SINEC-L2 data link Network Architecture of the New Oconee PPS mRV Nn > NRC Meeting - December 13, 2006 77

TELEPERM XSTM Gateway mRV Nn > NRC Meeting - December 13, 2006 78

External Communication via TELEPERM XS Gateway MSI Computer:

Qualified data transmission Gateway:

barrierin the security Transforms TXS-Ethernet protocol concept Into external system's protocol TXS Ethernet -+ -4m e.g. ModBus, OPC MSI Computer I

TIZI P.1DIZIAA Non-safety /&C.

Safety I&C Process Comp~uter 79 AREVA NP Inc > NRC Meeting

> NRC December 13, Meeting-- December 2006 13, 2006 79

Regulatory Evaluation Robert Gill 80 80 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 80

Applicable Regulations and Regulatory Guidance

> Regulations

  • Requires compliance with IEEE 603-1991, Criteria for Safety Systems for Nuclear Power Generating Stations

> Regulatory Guidance

  • RG 1.152 endorses IEEE 7-4.3.2-2003, Standard Criteriafor Digital Computers in Safety Systems of Nuclear Power GeneratingStations
  • Standard Review Plan SRP Appendix 7.0-A, Review Process for Digital Instrumentation and Control Systems SRP Appendix 7.1-C, Guidance for Evaluation of Conformance to IEEE 603 SRP Section 7.9, Data Communication Systems, in NUREG-0800 81 AREVA NP Inc L > NR

> December 13, Meeting -- December NRC Meeting 2006 13, 2006 81

InterchannelCommunication Compliance

  • TELEPERM XS system meets IEEE 603 and IEEE 384 requirements for physical, electrical, and communication independence

" Equipment in different cabinets

" Fiber optics and qualified optical isolators

  • DPRAM buffering circuits

> TELEPERM XS design features ensure data communication between safety channels does not inhibit the performance of the safety function as required by IEEE 7-4.3.2 and conforms to associated regulatory guidance (i.e., RG 1.152, SRP 7.1, SRP 7.1-C and SRP 7.9)

Strictly cyclic processing of application software

  • Asynchronous operating system
  • Static memory allocation
  • Message transfer controls
  • Absence of process-driven interrupts Constant load on bus systems C

> TELEPERM XS signal validation techniques improve system performance and meets IEEE 603 and IEEE 379 requirements

" Error propagation barriers

  • Not vulnerable to single failures

" Additional fault detection and accommodation capabilities 82 AREVA NP Inc > NRC

> Meeting -- December NRC Meeting 13, 2006 December 13, 2006 82

Communication with Service Unit Compliance

> TELEPERM XS system meets IEEE 603 and IEEE 384 requirements for physical, electrical, and communication isolation

" Fiber optics and qualified optical isolators

" DPRAM buffering circuits

> TELEPERM XS design features ensure data communication between safety channels does not inhibit the performance of the safety function as required by IEEE 7-4.3.2 and conforms to associated regulatory guidance (i.e., RG 1.152, SRP 7.1, SRP 7.1-C and SRP 7.9)

  • Strictly cyclic processing of application software Asynchronous operating system
  • Static memory allocation
  • Message transfer controls
  • Absence of process-driven interrupts
  • Constant load on bus systems

> Oconee design provides multiple layers of access control to prevent unauthorized access to or use of the MSI as required by IEEE 603, IEEE 7-4.3.2 and conforms to associated regulatory guidance (i.e., RG 1.152, SRP 7.1, SRP 7.1-C and SRP 7.9)

  • All equipment located in control room
  • Controlled access location within control room for service unit Key lock controls
  • Password/privilege controls 83

> NRC Meeting -- December NRC Meeting 13, 2006 December 13, 2006 83 I AREVA NP Inc IL

Communication with Gateway Compliance

> Oconee design provides one-way communication to the Gateway as required by IEEE 603, IEEE 7-4.3.2 and conforms to associated regulatory guidance (i.e., RG 1.152, SRP 7.1, SRP 7.1-C and SRP 7.9)

AREVA NP Inc > NRC Meeting - December 13, 2006 84

Acronyms

> CPU: Central Processing Unit

> CRC: Cyclic Redundancy Check

> DCS: Data Communication System

> DPRAM: Dual Port Random Access Memory

> EPROM: Erasable Programmable Read Only Memory

> EEPROM: Electrically Erasable Programmable Read-Only Memory

> ESF: Engineered Safety Feature

> ESFAS: Engineered Safety Feature Actuation System

> FB: Function Block

> FDG: Function Diagram Group

> HW: Hardware

> I/O: Input/Output

> ID: Identification 85 AREVA NP Inc I

L > NRC Meeting

> NRC 13, 2006 December 13, Meeting -- December 2006 85

Acronyms

> MSI: Monitoring & Service Interface

> OAC: Operator Aid Computer

> PPS: Plant Protection System

> RAM: Random Access Memory

> RPS: Reactor Protection System

> RTE: Runtime Environment

> SER: Safety Evaluation Report

> SPACE: Specification and Coding Environment

> SRP: Standard Review Plan

> TCP/IP: Transmission Control Protocol/Internet Protocol

> TXS: TELEPERM XSTM AREVA NP Inc > NRC Meeting - December 13, 2006 86