Digital Systems in Nuclear Power Plants System Design, Compliance, Challenges

1
Digital Systems in Nuclear Power Plants System
Design, Compliance, Challenges
Date November 4, 2008 Clayton Scott
2
Presentation Topics

• Nuclear Moving Forward
• Typical Architectures
• Platforms
• Compliance
• Global Standards
• Vendor Challenges
• Engagement of Stakeholders
• Challenges
• Common Issue to All
• Common Cause Failure (CCF)
• Licensing Positions
• Summary

3
Nuclear Moving Forward

• Existing plants are modernizing to digital
  equipment
• Developing new standards
• Limited number of qualified suppliers
• Different Licensing and Operational Philosophies
• New Plants Being Constructed Using Digital
  Technology
• Not all Reactor Suppliers have Finalized IC
  Design
• New Suppliers entering the market evaluating
  new technology
• Digital Requirements Differ from Regulator to
  Regulator Globally

4
Typical Architectures
5
Typical Architectures

• New Plants
• All Digital currently only 4 in the world N4
  (France), K6 K7 (Japan), Lungmen (Taiwan)
• NSSS May provide new reactor design IC
  technology may be behind
• Not all new plant designs have been fully
  approved IC typically last piece to be
  reviewed and approved
• Most Architectures have Digital Safety Qualified
  Reactor Protection and Actuation systems, Digital
  nuclear island, Digital display systems, advanced
  alarming systems, minimal conventional controls
  for accident purposes
• Advanced communication networks

6
Typical Architectures

• Existing Plants
• Tried to complete large scale control room
  modernizations most have failed to date
• More effective to perform small upgrades with an
  ultimate global modernization plan
• Example replace turbine controls, feedwater,
  chiller control, etc.. However, placing a
  communication infrastructure to tie all of these
  systems together in an overall control scheme one
  all of the systems have been upgraded. Hybrid
  approach less risk to operations
• Safety Related systems are still a challenge for
  some utilities and vendors
• Long Approval Cycles
• Main issues driven by technology and regulation
  positions
• Goal is standardization of systems

7
Platforms

• Limited number of 1E U.S. qualified suppliers
• IPS Tricon
• Westinghouse Common Q
• AREVA/Siemens Teleperm
• FPGA technology being reviewed as a potential for
  simplified logic and diversity

8
Compliance
9
Global Standards

• Multiple Standards Committees
• IEC, IEEE, MIL, IAEA, DIN, EPRI etc
• Many of the Standards are for the same purpose,
  but have slight differences
• No formal GAP analysis made to understand the
  true Deltas
• Most Challenging for Vendors
• Challenging for Regulators reviewing Vendor
  Qualification Submittals
• Challenging for End Users Specification
  Development
• NEA is sponsoring a project to the Digital IC
  Working Group (DICWG) called the Multinational
  Design Evaluation Programme (MDEP)
• MDEP is working to establish reference regulatory
  practices and regulations to enhance the safety
  of new nuclear reactor designs and increase
  cooperation among regulators to improve the
  effectiveness and efficiency of regulatory design
  reviews.

10
Vendor Challenges

• Global Suppliers most affected by differing
  Standards
• Must comply to multiple Standards to meet plant
  design and licensing criteria as well as Country
  Regulations
• Results in higher supplier costs
• Limits the number of suppliers to the industry
• Not cost effective for smaller companies to
  compete
• Industry could potentially exclude strong
  technology
• EPRI TR-107330 opened market to COTS suppliers
• Varying standards drives vendors to expend
  resources on compliance instead of improving the
  breed

11
Engagement of Stakeholders

• Regulators
• Evaluate performing a gap analysis of the main
  standards groups to provide a common
  understanding or guide on the requirements for
  Digital IC
• Do the regulators understand the impact that they
  have on obsolescence issues?
• Unique rules for equipment qualification places
  suppliers in a non-tenable business position.
• Non-viable product lines become obsolete quickly
• Obsolete equipment in power plants causes well
  known commercial and quality problems
• Are Regulators reviewing each others approval
  requirements to determine more consistent
  Standards use
• Should there be one common set of Standards for
  Digital IC?

12
Engagement of Stakeholders (cont.)

• End-Users
• Equipment Specifications -
• Are they written to fulfill your dream system?
• Are they written without the knowledge of
  industry standards in use elsewhere?
• Should be written to satisfy the safety and
  reliability needs of your plant while supporting
  long term maintainability (or you will be doing
  this again very soon!)
• Should not require or request custom circuitry of
  any kind.
• Guaranteed immediate obsolescence.

13
Engagement of Stakeholders (cont.)

• Manufacturer/Suppliers
• We must learn to say NO and push
• Many companies want the business to support
  today's profit margins, and are willing to sell
  anything with
• No thought to the clients future obsolescence
  issues
• Work with end users to reduce the number of
  non-required standards in their specification
• Work with Standards committees to be more
  consistent with each other
• Work with Standards committees to define or make
  aware manufacturers limitations
• Work with Regulator to ensure that product meets
  the licensing requirements based on Standards

14
Engagement of Stakeholders (cont.)

• Standards Committees
• Work with Regulators to understand the common
  issues
• Work with Manufacturers to understand their
  limitations and impact of certain requirements
• Share or Communicate with other Standards
  committees to share commonalities or differences
• Example IEEE and IEC

15
Challenges
D3
16
Common Issue to All

• Diversity and Defense-in-Depth (D3)
• One of the most common issues to all Digital
  Suppliers and Users
• Most controversial
• Standards not necessarily clear
• Left to Interpretation in some cases
• Basis The need to mitigate or eliminate Common
  Cause Software Failures in Digital Safety Related
  Systems

17
Common Cause Failure (CCF)

• If a postulated common-cause failure could
  disable a safety function, a diverse means, with
  a documented basis that the diverse means is
  unlikely to be subject to the same common-cause
  failure, should be required to perform either the
  same function as the safety system function that
  is vulnerable to common-cause failure or a
  different function that provides adequate
  protection.
• The diverse or different function may be
  performed by a non-safety system if the system is
  of sufficient quality to perform the necessary
  function under the associated event conditions.
  Reference BTP 7-19-3, Rev. 5 2007

18
Common Cause Failure (CCF)

• Software cannot typically be proven to be
  error-free and is therefore considered
  susceptible to common-cause failures because
  identical copies of the software are present in
  redundant channels of safety-related systems
  Reference BTP 7-19-3, Rev. 5 2007

19
Licensing Positions

• What does this mean?
• In the U.S., the industry and the NRC have taken
  the position that if a common platform is used
  for RPS and ESFAS then a diverse system must be
  implemented. Common Platform Common Operating
  System
• Some are challenging this position today and
  are yet to be approved

20
D3 Architecture BTP 19 Based
21
Licensing Positions

• Some Countries are accepting a common operating
  system with application software diversity and
  application functional diversity No Diverse
  System
• Some Countries are requiring two diverse hardware
  and software systems for Reactor Control and
  Reactor Trip
• Others looking at FPGA technology for the Reactor
  Trip and/or the diverse system

22
Summary

• The industry is sharing all the same issues
• Compliance is difficult due to lack of clarity
  and uniformity in the regulations
• Notable Challenges
• Large digital retrofits have failed, a well
  thought out incremental plans is required
• We need more collaboration amongst the four
  stakeholders
• Users
• Regulators
• Industry Associations
• Vendors
• It is an exciting time moving forward and
  Invensys is eager to get started