ML063530433
ML063530433 | |
Person / Time | |
---|---|
Site: | Oconee ![]() |
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
> 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
- 10 CFR 50.55a(h), Protection and Safety Systems
- Requires compliance with IEEE 603-1991, Criteria for Safety Systems for Nuclear Power Generating Stations
> Regulatory Guidance
- Regulatory Guide 1.152, Criteria for Use of Computers in Safety Systems of Nuclear Power Plants
- 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
> 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
> 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