Assessment of I&C Problems of the EPRStudy commissioned by Greenpeace Nordic

2010-10-04

Dr. Colin Hirsch, Perugia, Italy

in collaboration with

Dr. Helmut Hirsch, Neustadt, GermanyAdhipati Y. Indradiningrat, Neustadt, Germany

“The differences between theory and practice are greater in practice than in theory.”

1

Table of Contents

..................................................................................................................Introduction! 3...........................................................................Overview of Current EPR Projects! 3

.......................................................................Role of I&C in a Nuclear Power Plant! 4...............................................................................................The EPR I&C Sytems! 5

..........................................................................................................Important Issues! 7....................................................................................Issue 1 - Software Reliability! 7

......................................................................Issue 2 - Architectural Shortcomings! 10........................................................Issue 3 - Commoditization and Consolidation! 11

.........................Issue 4 - Full Disclosure of AREVA Software and Documentation! 13............................................................Issue 5 - Quality of AREVA Documentation! 14

..............................................................................Position of Regulatory Authorities! 16...................................................Remaining Problems and Possible Consequences! 18

..................................................................................Issue 1 - Software Reliability! 18......................................................................Issue 2 - Architectural Shortcomings! 18

........................................................Issue 3 - Commoditization and Consolidation! 19.........................Issue 4 - Full Disclosure of AREVA Software and Documentation! 19

............................................................Issue 5 - Quality of AREVA Documentation! 20................................................................................................................Final Words! 21

.......................................................................Cyber Warfare and Cyber Terrorism! 21...............................................................................................................Bibliography! 23

......................................................................................Abbreviations and Acronyms! 26

2

Introduction

Overview of Current EPR Projects

One of the so-called Generation III Pressurised Water Reactor types is AREVAʼs EPR. Its design is “evolutionary”; it was developed on the basis of the N4 and KONVOI reactors, the latest of the Generation II reactors in Germany and France, and is not radically different. (Almost all current commercial reactors are Generation II, and Generation III is currently being introduced.)The EPR design is a result of the co-operation between the French and German power plant vendors Framatome and KWU/Siemens, together with the French EDF and the major German utilities such as E.ON, EnBW, and RWE Power, and in collaboration with the safety and regulatory authorities from these two countries. The EPR has a high power output of approximately 1600 MWe. There are some new features which are intended to improve the safety level; other modifications constitute a reduction of safety margins. It is not immediately apparent, and there is no guarantee, that the safety level of the EPR is significantly higher than that of its predecessors [HIRSCH 2005].There are currently four EPR units under construction worldwide. In the US and UK, the EPR is undergoing the licensing or pre-licensing process.

EPR units under construction worldwide

Name Location Start of construction

Estimated start of commercial operation

Olkiluoto-3 Finland August 2005 2013Flamanville-3 France December 2007 2014Taishan-1 China October 2009 2013Taishan-2 China April 2010 2015

The construction of Olkiluoto-3 in Finland started in Summer 2005. The unit was originally planned to enter commercial operation in Spring 2009, however several problems emerged during the construction process, such as irregularities in the concrete used for the foundation, heavy forgings that were below project standards and had to be re-cast, deficiencies in the pipe welding, and issues with the EPRʼs new I&C systems, have delayed completion of the reactor. The latest estimates speak of Olkiluoto-3 starting operation in 2013, almost 4 years behind the original schedule, and with a cost overrun of over 2 billion Euros.The construction of Flamanville-3 in France is experiencing similar problems. Since the start of construction in December 2007, the project has suffered accumulated delays due to problems with civil works, welding, component manufacturing, and the

3

architecture of the I&C systems [NW 2010]. The Flamanville-3 unit is currently 2 years behind schedule.As noted above, one key cause for the delays of the two European EPR units is issues with the architecture of the plantsʼ digital I&C system. Architecture refers to the overall layout of the I&C systems and their interconnections. The British, Finnish, and French nuclear safety regulators have issued a joint statement that listed the key issues and demanded specific improvments from AREVA regarding the I&C systems for its EPR design [EU 2009].It was stated that the I&C systems designed for the EPR, as originally proposed by AREVA and the licensees, was found to contain a too high degree of complex interconnectivity between the control and safety systems, and therefore not comply with important independence principles [EU 2009].From the beginning, Finnish Radiation and Nuclear Safety Authority STUK required an additional and independent non-computerised backup system, and regulators in the UK have said that they might require similar measures, though a formal ruling on the matter is still pending [NW 2009b]. This report will look further into the issues regarding the I&C systems of the EPR.

Role of I&C in a Nuclear Power Plant

The three major functions of the I&C system in a nuclear power plant are monitoring, control, and protection. The I&C systems should provide accurate and appropriate information to the plant operators and permit judicious action during both normal and abnormal operation. They are used to control all the normal operations of the reactor, in startup, power operations, shutdowns and plant upsets. And they also have the task to protect the power plant from the consequences of any mistakes which the operator may make [IAEA 1999].The I&C systems of a nuclear power plant are divided into two categories, the safety systems and the non-safety systems. The non-safety I&C systems are in charge of monitoring and controlling the normal operation of the nuclear power plant, including startup and shutdown, and also for preventing off-normal conditions of the plant. It includes all facilities, loops and auxiliary systems that are needed for normal operation.The safety systems are designed to take automatic action to prevent and mitigate the consequences of faults and accident conditions in cases where the operators and the non-safety systems fail to maintain the plant within normal operating parameters.When necessary, the safety systems will at first undertake “soft” protection measures to bring the plant back to normal operating conditions. If these actions are not sufficient, the safety systems will automatically take action to rapidly shutdown the reactor (known as “scram”) and trigger any other systems required to mitigate the detected problem, and place the plant in a safe state. These safety systems are redundant, and usually designed to be as independent as possible from the non-safety control systems.

4

Currently, digital based systems are replacing older analog based systems and becoming more and more wide-spread in all industrial sectors, including the nuclear industry. Digital technology has already been used for several years in nuclear power plants for non-safety applications, but only recently has it started to be used for safety-critical systems in nuclear power plants.The reason for the transition to digital I&C systems is obvious cursory advantages over analog I&C systems. They have higher data handling and storage capacities, allowing for more operating conditions to be measured, recorded, and displayed. The software controlling their behaviour is more flexible and can be more easily adapted and extended to the target application. They also have better self-monitoring capabilities. Finally, they can be more efficient than the analog systems in terms of spatial use and wiring effort. It is also becoming harder to find spare component parts for analog I&C systems because vendors have been “going digital” and reducing their maintenance and support capacities for analog equipment.For these reasons, the increasing use of digital I&C technology in nuclear power plants is in some sense inevitable, for which the design of the EPR can be seen as prominent example. The original design of the I&C systems for the EPR is based exclusively on digital systems. As mentioned above, the Finnish regulator, STUK, has already requested analog back-up systems, and UK regulators are considering making a similar requirement.

The EPR I&C Sytems

The EPR I&C systems are based on the Teleperm XS safety I&C system supplied by AREVA, and the SPPA-T2000 operational I&C system from Siemens.According to the supplier, Teleperm XS is a digital I&C system that has been specifically developed for safety or high reliability functions in nuclear facilities. It has been licensed in Argentina, Bulgaria, China, Finland, France, Germany, Hungary, Slovakia, Sweden, Switzerland and the US. AREVA claims that the Teleperm XS system platform meets the most stringent requirements of international codes and standards and is the most advanced safety I&C equipment on the market. Teleperm XS, as installed in many different types of nuclear facilities worldwide, is designed to perform a variety of different applications, such as Reactor Protection and Limitation, Reactor Control, Turbine Protection, and more. The design of this system platform is guided by clear comprehensive principles. The supplier also claims that the system software and the application-specific software are separated, and that the hardware components of Teleperm XS have been certified according to international standards to be resistant to harsh environmental conditions such as temperature swings, vibration, seismic activity, and electromagnetic radiation [AREVA 2008].

Teleperm XS is currently installed in 49 nuclear power plants in 12 countries, with several different reactor designs [WEBER 2008]. For example in Germany, Teleperm XS has been deployed in Unterweser [E.ON 2004], Biblis B [VENCEL 2006], and also in Neckarwestheim-1 and 2 [WEBER 2008]. In Germany, it is not being used for

5

reactor protection systems so far, but only for reactor control and limitation systems, steam generator level control etc. Use for reactor protection has been applied for, but has not yet been licensed.Some other examples of reactors that use Teleperm XS are the Tianwan-1 and 2 units in China, Oskarsham-2 in Sweden [WEBER 2008] and the Beznau-1 and 2 in Switzerland [HANGARTNER 2005].

Examples of new reactors other than the EPR that will be equipped with Teleperm XS are the Mochovce-3 and 4 units in Slovakia, which are based on Soviet WWER (Pressurized Water Cooled and Water Moderated) technology [AREVA 2010].

The other platform, SPPA-T2000, formerly known as Teleperm XP, has been deployed to different types of power plants since 1993. SPPA-T2000 is dedicated to the automation of the power plant cycle. It condenses process information incrementally to give the operator the overview of the overall process at any given time, so that the operator can keep control over the plant processes and is able to maintain it safely and reliably since he can retrieve all levels of detailed information [SIEMENS 2010]. SPPA-T2000 is also going to be used in the Mochovce-3 and 4 units [AREVA 2010].The I&C systems in the EPR design are not completely new. Teleperm XS and SPPA-T2000 are both in active use in several existing nuclear power plants, and are scheduled to be installed in various new reactor builds. It is therefore safe to conclude that the problems discussed in this document are also relevant to other nuclear power plants beside the EPR. (Of course, the occurrence and severity of these problems will also depend on plant-specific conditions.) The issues addressed here will become more and more important in the future, since it can be expected that the trend for digital I&C systems to be more and more wide-spread in nuclear power plants will continue.

6

Important IssuesThe list presented in this section is a compilation of important issues regarding the safety of the EPR and its design in the light of a new generation of digital I&C systems. It is not necessarily exhaustive.These issues and questions are based on the HSE “Step 3 Control and Instrumentation Assessment of the EDF and AREVA UK EPR”, Division 6 Assessment Report No. AR 09/038-P, taking into account STUK decisions G332/55, G332/69 and G332/74, the “Joint Regulatory Position Statement on the EPR Pressurised Water Reactor”, and other publications from the national regulatory authorities, pertinent journals, direct communication with participating parties, and recent workshop proceedings on the subject of digital I&C.

Issue 1 - Software Reliability

The use of a digital platform introduces completely new challenges throughout the product life cycle, most of which are due to the required software, and the networking of computer systems. As seen in issue 2, the linking of digital components was already identified as contributing to the overall complexity of the I&C system.One of the main issues with software is the verification of its correctness and reliability. In 2009 the “Committee on the Safety of Nuclear Installations” published the results of a survey on the subject of “Assessing Digital System Reliability in Probabilistic Risk Assessments of Nuclear Power Plants” [CSNI 2009]. The survey showed that a wide range of different models and methodologies were employed, and that there was no clear candidate for an approach on which to base standards.Significant limitations were identified, for example many approaches did not take into account the — often decisive — effects of common-cause failure on the probabilities, or were unable to model certain parameters. For example, the AREVA/EDF approach was unable to take into account I&C failure due to human error.The recommendations spelled out in the CSNI report illustrate the fact that the evaluation of software reliability is still very much a work in progress. Indeed the first two items are recommendations to “develop a taxonomy of hardware and software failure modes of digital components for common use” and to “develop methods for quantifying software reliability”.This goal might not be easy to reach, as recent publications in the area of software reliability disagree. In particular the research of Prof. Littlewood, partly funded by the nuclear industry and/or performed in the context of HSEʼs evaluation of the EPR, gives little hope, as he states that “The problem of assessing the reliability is often more difficult than the problem of achieving that reliability, particularly when the reliability requirements are very stringent,” and a recent paper “shows that the levels of reliability that can be claimed with scientific justification are relatively modest” [LITTLEWOOD 2000a].

7

A further issue pointed out in the CSNI report was the insufficient availability of actual failure data, both for hardware, including CCF, and for software, which could give further indications as to which failure modes need to be included in future reliability models.Software can be more easily changed and extended than hardware, which can lead to more frequent updates that rectify problems or introduce new features. A report from the “Committee on Nuclear Regulatory Activities” notes that although “the time needed for the surveillance test of the digital plant protection system takes about 5 times longer than that of the analogue plant protection system”, creating a higher initial burden, the issue of software updates is indeed real as "According to COMPSIS (NEA Data Base Project on Computerised Systems Important to Safety) failures database, 70% of the failures are from the requirements, 5% from coding and 25% from maintenance and changes" [CNRA 2008].In other words, most failures are due to errors in, or interpretations of, the specification, followed by errors introduced after the software enters production, which fits the general picture of a software-based system being both more complex and more dynamic, than a hard-wired solution. This ability to [easily and frequently] change software requires elaborate configuration management procedures and systems to ensure that software and documentation are always synchronised, that only verified and tested versions of the software are deployed, that every change can be traced back to its origins, among others.The “Licensing of safety critical software for nuclear reactors — Common position of seven European nuclear regulators and authorised technical support organisations” report also acknowledges that “The quality of a piece of software can neither be quantified, nor tailored to demand”, and the NRC observes that “although a great deal of effort has been applied to develop highly reliable software with extremely low failure rates, current software engineering practice has not achieved the capability to prove quality and reliability (i.e., “error-free” software) through testing and analysis under all credible conditions” [EU 2010].The European report does list a large number of recommendations and best practices regarding the entire software lifecycle, however every single step also introduces new possibilities for error. For example, it is required that the same version of the compiler is used to compile every part of the software. The compiler itself must also be “validated”, and all optimisations must be provably correct. A new release of the compiler that changes the generated code requires re-testing the whole software.It could be argued that these quality requirements need to be applied to the complete software stack used for software design, development and management. This includes not only the actual software building tools like compiler and linker, but also the configuration management system and communication software used to distribute the digital files and finally the operating system(s) that host all these applications, because any single small piece of unverified software that touches the

8

I&C software or its configuration can potentially corrupt the files even before they are deployed into operation.In the case of the build software it might not be necessary to perform a full verification of the software as long as the output that it generatees can be verified, however the burden is then shifted to the software performing the independent verification of the result, and everything that the verification software in turn requires, including its operating system.In order to mitigate the effects of any single issue and guard against common cause failures, the report further recommends the principle of diversity for the whole software development process, including but not limited to multiple non-communicating development teams, functional diversity, diverse verification and validation, and diverse development platforms, tools, and compilers. Departure from diversity is not recommended and needs to be sufficiently justified.The difficulties in assessing the reliability systems in general, and of software-based systems in particular, have shown up in the discussions between the regulatory authorities and the supplier, in some cases leading to the introduction of non-computerised backup systems.For example, the probability of failure on demand claimed by AREVA and EDF was originally given as 10-5 and 10-4, respectively, for the Teleperm XS and SPPA-T2000 platforms. HSE found that these numbers were not sufficiently justified in the available documentation; further, HSE even hints at not considering these numbers to be justifiable at all [UK 2009, 2.3.2 paragraphs 18 and 19].AREVAʼs response to HSE regarding this issue included the reduction of the reliability claims for the two platforms, for Teleperm XS from a 1 x 10-5 PFD to a 1 x 10-4 PFD, and for SPPA-T2000 from 1 x 10-4 PFD to 1 x 10-2 PFD. Still assuming the best case of complete failure independence, the combined PFD went from 10-9 to 10-6, or a 1000-fold increase in failure probability.A non-computerized backup system is now to be implemented for the UK EPR with a 1 x 10-3 PFD in order to provide protection and controls in case of total loss of C&I functions from the digital systems, bringing the combined PFD of all three systems — again assuming independence — up to the level originally claimed for the two digital systems alone.This relatively large change in documented reliability of the major I&C components comes at a relatively advanced stage of the planning and construction process, and only after the originally claimed numbers were challenged by HSE. Seeing that the new numbers align with the PFDs for corresponding systems in the Sizewell-B NPP, which reflect the highest reliability claims deemed credible by HSE, they should have formed the basis for all further calculations.The assumption of independence of failures is the precondition to allow for the combined PFD of two or more systems to be obtained by multiplication of the individual PFDs. It has been questioned in [LITTLEWOOD 2010] whether this optimal case is at all achievable in practice, and pointed out that interdependent PFDs where the combined reliability is lower must be assumed. The research behind this

9

questioning is independent of the possible connection between the two computerised platforms mentioned below in Issue 3; many general aspects are taken into consideration, for example the observation that any part is more prone to fail in a “difficult” situation, which would be similarly “difficult” for any backup, too.Experiments have shown that design-diverse versions do not fail independently of one another [Knight and Leveson 1986b], however further research by Prof. Littlewood indicates that pairing a more complex primary system with a simple system, one sufficiently simple that the absence of design flaws is credible, can increase the compound reliability [LITTLEWOOD 2000b].It is known that STUK already required a non-computerized backup for OL3, prompting the question of which PFD numbers AREVA claimed towards STUK for OL3, and at which point in time relative to the dialogue between AREVA and HSE. Was the requirement for a backup established because STUK had no confidence in AREVAʼs claims to begin with, or were there any additional reasons? The inherent diversity? General mistrust of computerised systems for safety-critical tasks? The desire to keep the “old and trusted” technology around as backup? What was the course of the discussion of this issue between STUK and AREVA?

Issue 2 - Architectural Shortcomings

Several regulatory authorities currently evaluating the EPR have found the overall I&C architecture proposed by AREVA to be “overly complex” and interconnected, thereby violating several well-established design principles.For example, the TSC working for HSE concludes that "the submission made by EDF and AREVA for the overall C&I architecture of the UK EPR reactor does not demonstrate that the UK EPR C&I architecture is in accordance with many of the relevant principles, standards and guidance" [UK 2009, 2.3.2 para 23].One well-established design principle that is/was violated is that no system of a lower safety importance class may write to a system of higher safety importance class. "In particular, the major concerns remain over [...] inputs into the Class 1 system from non-Class 1 sources [...]" [UK 2009, 2.3.2 para 25]. This issue was present in the April 2008 edition of the PCSR for the UK EPR, and, although addressed by HSE, recurred in the — largely unchanged — June 2009 edition of the same PCSR [UK 2009].The importance of this design principle is generally recognised, for example the German Safety Criteria for Nuclear Power Plants [DE 2009] list it as a strict requirement, and recent communications from HSE, the NRC, and STUK point out unjustified non-adherence as an issue that needs to be resolved.For example in decision G332/74, STUK appears to address the same or a similar problem, although tersely formulated. “The independence requirement of YVL 5.5 section 3.5 being not fulfilled regarding the interface between PAS and SAS, elaborate justification showing that an equivalent level of safety is achieved has yet to be provided to TVO” [FI 2008].

10

Another design principle that is/was violated is that of simplicity, as emphasised by the NRC regarding the US-EPR. The overall complexity of the architecture was found to make verification of the adherence to current safety regulations difficult, rendering it unlikely that the design can be demonstrated to be adequate, in particular within the envisaged time frame [NF 2010]. In February, the NRC safety review was extended by six months, and the NRC also observes that “as design complexity increases, the feasibility of exhaustive testing or comprehensive formal proof diminishes considerably” [US 2009].The complexity was, again, at least partially attributed to the high level of interconnectivity between the individual components. It was again noted that further changes were required in order to provide for sufficient independence of safety and non-safety critical systems, in particular because the violations of the independence principle were not found justified in the existing documentation.In response, AREVA is willing to reduce the communication between independent safety systems, and between systems of different safety relevance, however even the currently planned “extensive revisions” will not suffice to eliminate all of the critical interconnections from lower-importance to higher-importance systems, and further documentation updates and discussions are scheduled for later this year with the explicit goal of demonstrating that the parts criticised by the NRC where AREVA wishes to retain the original design do indeed meet current requirements.Another instance of the EPR design departing from established simplicity principles implemented in other NPPs is that of the final actuation devices that are driven by the I&C system. The more complicated devices used in the EPR are recognised as particularly critical, being both a “potential site for a CCF vulnerability of the protective function”, yet not sufficiently simple to put CCF issues to rest [US 2009].

Issue 3 - Commoditization and Consolidation

The I&C system for the EPR is based on two platforms, Teleperm XS and SPPA-T2000 which, as noted in [UK 2009], might not be completely independent products."The two platforms Teleperm XS and SPPA-T2000 (previously known as Teleperm XP) appear to have potential common ancestry within the Siemens organisation. Their program development and execution models are also similar, based on the use of auto code-generation from function block diagrams, and supported by a library of runtime functions. Therefore the sufficiency of the claim of full diversity between these platforms (both in terms of development and in terms of execution) could not be established."Being based on different processors is not sufficient to ensure full diversity; the potential for CCFs can arise from many other commonalities like software model, or similar engineering applied to similar requirements, in particular within one company.These two platforms are jointly responsible for the 5 defence-in-depth safety levels referred to in IAEA Safety Standard NS-R-1.

11

! Level 1 - prevention of abnormal operation! Level 2 - control of abnormal operation, detection of failures! Level 3 - control of accidents within design basis! Level 4 - prevention and mitigation of severe accidents! Level 5 - mitigation of radiological consequences of releasesFor new reactors like the EPR, the design basis (level 3) is generally broader than for reactors currently in operation, and level 4 is taken into account to some extent in the design phase. In the context of the report at hand, mostly levels 1 thru 4 are relevant.The mapping of 5 safety levels to only two different platforms implies that a single system failure cause can simultaneously disable several security levels, as explained by [UK 2009]:"[...] the EPR design appears to align with the 5 levels referred to in IAEA Safety Standard NS-R-1. [...] The levels of Defence-in-Depth within the C&I system functional allocation relies on only two digital platforms TXS and SPPA-T2000 [...]"It is further noted that “there is a risk of a cascaded fault sequence”, here multiple faults occurring together at different levels of the defence-in-depth strategy, because of both single systems (for example the PAS) and single platforms (for example Teleperm XS) executing functions at different defence-in-depth levels. A single system or platform failure could simultaneously affect multiple defence-in-depth functions, effectively reducing the number of defence levels.The HSE documents do not contain an overview showing how the levels of defence-in-depth are mapped onto the two platforms. From the information provided, it can be concluded that SPPA-T2000 performs functions of, at least, safety levels 1, 2 and 4; whereas Teleperm XS performs functions of levels 2, 3 and 4 [UK 2009, UK 2009a].Further, if not fully diverse in hardware and software design and manufacturing, it is under no circumstances reasonable to assume independence of the failure probabilities mentioned in Issue 1. The absence of full diversity between the two platforms makes common-cause failures more likely, and would further increase the combined PFD of the two digital systems by a possibly large, but largely unknown, factor, in addition to the fact that perfect independence of failure is hard to claim even for fully diverse systems. In the worst case, or conservatively estimated, the aggregate PFD would only equal that of the more reliable of the two platforms alone.Another issue raised by the French ASN regarding the EPR Flamanville 3, for which no non-computerised backup system is currently envisaged, is that the distribution of functions between the two systems places some safety-relevant responsibilities on the SPPA-T2000 platform, which is a normal industrial product not developed to the much stricter requirements of nuclear facilities. It can be speculated that the effort to develop two independent nuclear-grade platforms would have had significant cost.More cost-cutting can be achieved by the adoption of commodity personal computers with standard PC operating systems in place of specialised computer systems. The EPR currently only employs commodity systems in non-safety-critical roles, for example as development platform. It needs to be strictly ensured that on-site

12

personal computers used e.g. for configuration or monitoring tasks are not connected to safety critical systems in a way that can adversely impact their operational reliability, or quietly subsume parts of their functionality.In 1997 the guided missile cruiser USS Yorktown (CG-48) was left dead in the water for several hours after its “Smart Ship”-technology based on Windows NT personal computers, for which the vessel served as a testbed, failed and locked up.Although the incident was not directly linked to the operating system, it was suggested that the choice of Windows NT made the whole setup more vulnerable to computer glitches, and has led to several other similar incidences [US1998].

Issue 4 - Full Disclosure of AREVA Software and Documentation

In order to ensure safe operation independent of the fate of a single vendor, STUK has formulated a requirement to enable 3rd-party suppliers to perform required maintenance of the I&C system:“[Definition of requirements] must be on a level that allows automation to be renewed even in a situation where AREVA cannot act as the supplier. Documentation must allow renewal to happen in parts” [FI 2008].This wording from STUK does not explicitly mention software, however even the hardware alone is noticeably more complex than a traditional I&C system. If the intention is to allow for 3rd-party suppliers to perform any upgrade or tuning of the system, this requirement would imply availability of the complete documentation of the software internals, the software and operating-system source code, as well as the software, sources and documentation of the complete software development tool chain, a highly significant increase in material that opens up a completely new area.The “Licensing of safety critical software for nuclear reactors“ [EU 2010] identifies independent assessment of software-based safety systems as “essential”. In this case, the full disclosure of all related software and documentation to one or more 3rd-parties is inevitable. Even though the 3rd-parties are not in a competitive situation with the supplier, the larger scope and volume of information, and the possibly larger number of involved parties required to cope with it, can pragmatically be seen as incresing the risk of unintended or accidental proliferation of documents, in particular in electronic form.Given the higher integration and complexity of the digital I&C platform proposed for the EPR, several issues regarding these requirements arise, not least that it is generally bound to, and possibly at the mercy of, a single vendor.

How is the lead-in time required by a 3rd-party supplier, before the knowledge and experience with the design and implementation of the I&C system necessary to perform these tasks is gained, affected by the choice of a proprietary and highly integrated digital I&C platform?

Given the presumably large investment in development of the I&C platform, can it be guaranteed that AREVA would be prepared to hand over sufficient documentation to potential competitors while conducting regular business?

13

In “Licensing of safety critical software for nuclear reactors“, one of the issues identified with independent assessment of the software is “Ensuring that independence does not deprive the assessors from access to all relevant information [...]”

Is it necessary and, if so, feasible to include the software in the “renewability” requirement?

Issue 5 - Quality of AREVA Documentation

Several of the issues listed above go beyond discussion and resolution of technical questions by the supplier and the regulatory authorities. Rather, as indicated by the following observations, there is mounting evidence that the supplier is unwilling, or unable, to provide sufficient documentation of the expected and required quality, and within the expected and required time parameter.

After the original numbers were challenged by HSE as unfounded, and therefore too optimistic, the aggregate reliability claimed for the I&C system by AREVA was reduced by a factor of 1000.

The design proposed by AREVA goes against well-established safety principles like keeping separate functions in separate components, simplicity and diversity, and strict defence-in-depth, examples of which were given in several other issues. These are principles that a company like AREVA must have been well aware of, which leads to the question of why these design principles were violated. The currently proposed solutions only now include — at least partial — rectification of these issues. Where adhering to the principles is possible, it should have been done so in the first places; all other cases should be sufficiently documented and justified. However:

The request for sufficient information and documentation in order to fully evaluate the proposed I&C solution, its architecture, and in particular the safety and reliability claims, has not been properly answered by AREVA for over a year. This unfortunate situation might cause further delays to the project. It is unclear whether AREVA is not able or not willing to come up with the required reasoning and documentation, and why, considering that according to the original schedule the first EPR should already have entered operation by now, the project could have progressed this far without a complete set of documentation.

Beyond the rejection of the orignally claimed reliability numbers, there were several other cases where the HSE assessment concludes that there were significant problems and undue claims in particular in the area of diversity. While AREVA has a longer history of designing and writing, for, and discussing with, the French regulatory authorities, with different priorities, trade-offs, and philosophies compared to their British or Finnish colleagues, it is alarming that safety-relevant design decisions and/or reliability numbers were found not

14

sufficiently explained and justified by several regulatory authorities. For further examples see Annex 4 in [UK 2009].

Why was Teleperm XP renamed, and how much joint history, design, engineering, or philosophy is there between Teleperm XS and Teleperm XP? AREVA or Siemens should provide sufficient insight into the history of the two platforms in order to evaluate the possibility of common cause failures due to overlapping engineering or design principles.

There is a fixed-price, turnkey contract between AREVA and the Finnish utility TVO. In autumn of 2009, AREVA admitted [NW2010] provisions of EUR 2.3 billion to offset potential losses. A more recent delay of further six-months brings the project to currently running four years behind the original schedule. This and any further future delay will “obviously” require further provisions against losses, which, although the actual losses will only be known once the contract is fulfilled, places a noteworthy financial pressure on AREVA to successfully conclude the project as fast as possible, thereby forming a financial incentive to sacrifice quality for speed.

15

Position of Regulatory AuthoritiesAs shown by several joint publications, there is a highly welcome exchange and collaboration between the different national regulatory authorities.All concerned national regulatory authorities have found significant, and significantly overlapping, issues with the I&C of the EPR that require significant amendments on the part of AREVA. The issues were both of a concrete nature, concerning actual shortcomings in the I&C design and architecture, as well as regarding substantial omissions of details and justifications of decisions in the documentation.Some of the issues were noted as severe enough to delay, and — if not resolved — potentially prevent successful completion of the projects. Progress has been steady but slow, with several new delays being introduced in 2010 even while some issues were, at least partially, resolved. For example, the HSE reports show that no significant progress regarding the shortcomings found by HSE in the I&C design was made between the PCSRs of April 2008 and June 2009, and a recent NRC letter to AREVA acknowledges that while some issues were addressed, others were still without resolution [S 2010].As stated in the “Joint Regulatory Position Statement on the EPR Pressurised Water Reactor” [EU 2009], the primary issue was that of “adequacy of the safety systems, and their independence from the control systems”. The “joint statement”, and other documents on public record from 2008 and 2009, like the “STUK decisions” [FI 2008] from 2008, and parts of the HSE reports [UK 2009] and in particular the regulatory issue “RI-UKEPR-002” [UK 2009b], have a somewhat severe and/or demanding tone that suggests a certain frustration in particular with the inability of AREVA to produce the required documentation.Recently however, although the demands for updated documentation have not yet been met, with delivery of some documents pending for the second half of 2010, Keijo Valtonen, deputy director of STUKʼs reactor regulation department, was cited in [NW 2010] seeing “no show-stoppers” despite some issues remaining, and being “confident” that with the proposed changes, in particular the additional back-up system required by STUK, the independence principle for safety and non-safety-class systems was being met.This suggests that, from the point of view of STUK, issue 2 (architectural shortcoming) of this document is in the process of being sufficiently addressed for OL3 by addition of the analogue safety system. While the issues being addressed are similar for the other EPR projects, there might be some divergence in the solutions. The UK EPR will be fitted with a similar non-digital safety-system, however for Flamanville-3, EDF has stated that it would like to convince the regulatory authority to accept the original design. Then again, recent news indicates that safety functions would need to be duplicated in the Teleperm XS system in order to prevent reliance on the non-nuclear-grade SPPA-T2000 for such tasks [NW 2009].Issue 1 of this document (software reliability) touches an area where it is widely understood, as shown for example by the CSNI report, that the methodology for evaluating the reliability of safety-critical software is both a very difficult problem, and

16

very much a work in progress. Yet, the issues raised by the regulatory authorities do not explicitly question either the decision to “go digital” at this point in time, or the reasoning behind the reliability claims (although some of the requested clarifications regarding various aspects of the I&C system might touch the subject of software reliability).The reasons for this seeming omission on the side of the authorities remain unclear. Perhaps the issue is not recognised as being fundamental to the evaluation process, or the other issues have — temporarily? — postponed dealing in-depth with the “software questions”, limiting the dialogue to subjects where there is a background of decades of dealings between the suppliers and the authorities. Or “going digital” and with all its consequences is seen as inevitable progression, and is therefore not questioned.It is further unclear, when the other national regulatory authorities concerned with an EPR project were made aware of the reduction in claimed reliability, or whether the same platform would be evaluated differently in different countries, and what the possible influences on their respective positions were. No public reaction has come to our attention. HSE has, however, stated that it expects further justification from AREVA regarding the independence of the PFDs of the two computer platforms, a key issue for the reliability claims.Although the core of issue 3 (commoditisation and consolidation) of this document was raised by HSE, it is still unclear to what degree relationship between the two digital platforms exists, and what consequences would (need to) be drawn by the regulatory authorities.Regarding issue 4 (full disclosure of software and documentation) we do not have any information on whether, and to what extent, other regulatory authorities are following up on the possibility or necessity of 3rd party maintenance, and what the exact scope of the requirement is, or whether a full independent assessment of the software systems is scheduled.Issue 5 (quality of AREVA documentation) has been a consistent point in the communications from the regulatory authorities to AREVA. (At least) for the EPRs in Finnland, the UK and the US, significant updates to the documentation are pending a promised delivery later this year. Although some issues with the documentation are/were significantly severe to (threaten) delaying the respective projects, it appears that the authorities expect adequate documents to be eventually presented.

17

Remaining Problems and Possible Consequences

Issue 1 - Software Reliability

There seems to be no reliable, generally recognized method for assessing failure probabilities of digital I&C systems; the area is acknowledged to still be very much work-in-progress. It is particularly problematical to determine failure probabilities for a combination of systemsThis implies a general increase in the uncertainty regarding the probability of a severe accident if digital I&C systems are used and as long as this problem is not resolved. Once methods advance, incorporating in particular research on the limits of the reliability of the reliability assessment, it might also turn out that the currently assumed reliability is too optimistic, and that the current generation of digital I&C systems, or even any software-based system in general, is not sufficient.It might be possible to mitigate the problem by adding non-digital systems, albeit at the cost of introducing further components, and therefore further complexity. The question must be allowed as to why a digital system was chosen at this point in time, and whether implementing such a system should not wait for reliability assessment to catch up with the engineering possibilities, and relegate computerised systems to non-safety-critical tasks for the time being.

Issue 2 - Architectural Shortcomings

The choice of a digital I&C platform is greatly increasing the complexity of the design, implementation and verification of the system. This increase in complexity comes in many different forms, more complicated hardware components and more components in the system, more connections and networking, plus the new items system software, application software, management software, versioning software, verification software, development software etc.This places a greater burden on both the supplier, to demonstrate the adequacy of the proposed solution, as well as the authorities who need to verify the claims, support the supplier in resolving possible issues, and ensure that no new failure modes are introduced by the consolidation and internetworking of components. The existing delays in current EPR projects, for which this issue is also responsible, indicate that, again, it must be questioned whether a digital system was the right choice – whether the inherent complexity does not outweigh any potential benefits, at least for safety-relevant systems.With the issues of incomplete documentation and much longer review times, the original schedules appear as too ambitious, in particular if the sensible, but hard to achieve requirement to evaluate all software included in the creation of the digital I&C platform, or at least its software, is to be fulfilled.

18

It must now be ensured that, although it can be stated with confidence that even with the amendments proposed by AREVA the final system will be significantly more complex than previous-generation I&C systems, no last-minute cutting of corners is done.For example, in the UK and Finland, it is unclear whether the aforementioned addition of a non-computerised backup system is intended to demonstrate sufficient independence between a safety-relevant system and the non-safety-relevant systems, or whether it is necessary and/or required to disentangle the digital part of the I&C system, too. Does adding the backup system replace some of the complexity in the (interconnection of the) digital systems, or does it enable their acceptance by lessening the reliability burden?In France, it is unclear whether and why the duplication of safety-critical tasks from the SPPA-T2000 platform to the Teleperm XS system should increase the overall reliability, in particular against CCFs.The regulatory authorities must be free to face the increased challenge of evaluating the new NPPs with no undue political, financial or temporal pressure, and with the capacity to enact any changes deemed necessary for safety, regardless of the scope and scale. Otherwise there is a risk that the pressure could have a derogatory effect on regulatory scrutiny.

Issue 3 - Commoditization and Consolidation

The great(er) complexity of a digital I&C system and accompanying high cost of development, culminated in a design based on two platforms, of which only one was developed to nuclear-grade quality standards. This issue appears unresolved for the systems to be used for the EPR, and it is possible that it will recur for other NPP designs which are using digital I&C.The uncertainties regarding the general reliability of the I&C installations as a whole are further increased by this problem. Given the new problems of reliability, assessment of reliability and complexity brought by the introduction of digital I&C systems, the question must be asked whether the choice to “go digital” was itself driven by cost and commoditization concerns, and whether this is an appropriate direction for safety-relevant systems in a nuclear environment.The question of whether the failure probabilities of the two digital platforms Teleperm XS and SPPA-T2000 are independent, independent of how close a joint history they share, needs to be resolved, and the consequences regarding the diversity and reliability analysis drawn to full conclusion. If the independence claim breaks down, the PFD shown in issue 1 could become worse by another factor of 100.

Issue 4 - Full Disclosure of AREVA Software and Documentation

19

The necessity to involve a third party deeply in all details of the hardware and software used for I&C creates problems which have not been encountered before, in this drastic form, in the nuclear sector. If the information flow between original system developer and supplier, and the new party brought in for assessment, or maintenance and renewal, a pandoraʼs box of new hazards is opened.Each additional party involved requires its copy of the complete set of data, source, and documentation, some of which might, in particular prior to entering operation, change frequently, and/or be available only in electronic form. A perfectly functioning version management across all parties is required to prevent things like untested software versions, or not jointly tested combinations of hardware, software, compiler, and operating system versions and their respective configurations, entering operation.An example of the consequences of the synchronisation of infrastructure and processes failing between cooperating entities is the 2004/2005 Airbus A380 production delay caused by incompatible versions of the design software [NYT 2006]. In this case the problem appeared early, and only financial losses were incurred, however it shows the risks of bringing more and more components, in the form of software, into the process.

Issue 5 - Quality of AREVA Documentation

The optimistic assumption is that the still-missing documentation from AREVA will put to rest the issues regarding architectural shortcomings and unfounded safety claims brought forth by the regulatory authorities. Once this documentation is available, the authorities must be given enough time to ensure that this is indeed the case, and that no other safety-relevant omissions are still present, independent of any -- past, or possible future -- delays.These delays are due to all involved regulatory authorities requiring non-trivial amendments to the documentation, and the architecture, in most cases including the addition of a non-computerised safety system. AREVA might have been overly optimistic regarding the wide-spread acceptance of its original computer-only I&C system. At this point it can only be hoped that the reasons for this optimism are well founded, the missing documentation and issues collected here notwithstanding.

20

Final Words In general, the use of digital I&C creates new problems, which can lead to new safety hazards. Furthermore, it becomes more difficult to assess those hazards; the uncertainties of risk assessments are increased.The choice of AREVA to originally propose the EPR with only computerised I&C systems is leading to significant differences between the final I&C architectures in the different EPR projects, requiring several similar-yet-different versions of the application software, and further amplifying the already significantly higher software testing and version management burdens for AREVA.Given all the issues found by the authorities, of which some are listed in this paper, and the countless small and large disasters linked to software failures [RISKS], it must be questioned whether, at this point in time, the digital I&C system for the EPR is really the right choice for safety-critical tasks in a nuclear power plant.

Cyber Warfare and Cyber Terrorism

As with all new technologies, the new possibilites and capabilities can used in both beneficial and malicious ways. In the case of computerised I&C systems, the same mechanisms that allow for greater diagnostic possbilities, and for remote monitoring, controlling and updating, can be potentially exploited by cyber-attacks, as shown by the recent Stuxnet computer virus that targets Simatic programmable logic devices, a kind of industrial computers by Siemens [SYMANTEC 2010].At the time of writing, neither the complete functionality, nor the exact target of Stuxnet is fully known. There is, however, reason to believe that a similar or more evolved piece of malware could pose a threat to NPPs, and in particular to those equipped with digital I&C systems.In order to compromise industrial computer systems, Stuxnet first targets personal computers running the common Microsoft Windows operating system. It exploits multiple security vulnerabilities in Windows to spread from computer to computer, via both computer networks and interchangeable media (for example USB sticks). It then proceeds to attack certain industrial computers that are attached to an infected PC, and is capable of modifying the software on the Simatic device, and hiding the changes.Stuxnet also shows that the possibility of cyber attacks against previously rarely targeted industrial computers might not have been treated with the required seriousness. While it is true that the industrial application that is attacked by Stuxnet is protected by a password, the manufacturer itself has advised to not change the default password to another value as “that could impact plant operations” [CNET 2010], a step that effectively disables the password as means of access control.Stuxnet was noted for its great sophistication regarding the multitude of exploited weaknesses and measures to avoid detection, and the virus was in the wild for at least several months before being detected and before counter measures were

21

introduced. In principle, a similar or even more sophisticated virus could (also) target digital I&C systems in nuclear power plants, possible by even more indirect attack paths.(At the time of writing it seems clear that Stuxnet was designed to attack a very particular application, however it was not clear whether an Iranian NPP was the target, and whether the attack was successful.)

22

Bibliography

AREVA 2008 AREVA NP, “Teleperm XS in Brief”, Erlangen 2008

AREVA 2010 AREVA and Siemens press release, “AREVA and Siemens Consortium to Supply Digital Supervision, Protection and Control Systems for Nuclear Power Plant in Slovakia”, April 2010

CNET 2010 Tom Espiner, “Siemens warns Stuxnet targets of password risk”, cnet news, July 2010, at http://news.cnet.com/8301-1009_3-20011095-83.html

CNRA 2008 OECD Nuclear Energy Agency, “Proceedings of the Committee on Nuclear Regulatory Activitiesʼ 2007 Workshop on Inspection of Digital I&C Systems - Methods and Approaches”, July 2008

CSNI 2009 OECD Nuclear Energy Agency, Committee on the Safety of Nuclear Installations, “Recommendations on Assessing Digital System Reliability in Probabilistic Risk Assessments of Nuclear Power Plants”, December 2009

EON 2004 e.on Kernkraft, “Einsatzerfahrungen mit TELEPERM-XS (TXS) im Kernkraftwerk Unterweser”, Presentation, Berlin 2004

EU 2009 HSE (UK), ASN (France), STUK (Finland), “Joint Regulatory Position Statement on the EPR Pressurised Water Reactor”, October 2009

EU 2010 BEL V (Belgium), Bundesamt für Strahlenschutz (Germany), Consejo de Seguridad Nuclear (Spain), ISTec (Germany), HSE Nuclear Installations Inspectorate (UK), Strålsäkerhetsmyndigheten (Sweden) and STUK (Finland), “Licensing of safety critical software for nuclear reactors --Common position of seven European nuclear regulators and authorised technical support organisations”, Revision 2010

DE 2009 Bundesministerium für Umwelt, Naturschutz und Reaktorsicherheit, “Sicherheitskriterien für Kernkraftwerke”, Revision D, April 2009.

FI 2008 STUK letter to TVO with regulatory decisions regarding Olkiluoto 3, July 2009

HANGARTNER 2005

C. Hangartner, “Ersatz des Reaktorschutz- und Regelsystems im Kernkraftwerk Beznau”, International Journal for Nuclear Power “atw”, 2005

HIRSCH 2005 Helmut Hirsch (lead author), "Nuclear Reactor Hazards - Ongoing Dangers of Operating Nuclear Technology in the 21st Century", Report for Greenpeace International, April 2005, at http://www.greenpeace.org/international/Global/international/planet-2/report/2006/8/nuclearreactorhazards.pdf

23

IAEA 1999 IAEA, “Modern Instrumentation and Control for Nuclear Power Plants: A Guidebook”, Vienna 1999

LITTLEWOOD 2000a

Bev Littlewood, “The Problems of Assessing Software Reliability ... When you really need to depend on it”, in “Proceedings of the 8th Safety-Critical Systems Symposium”, May 2000

LITTLEWOOD 2000b

Bev Littlewood, “The use of proof in diversity arguments”, in “IEEE Transactions on Software Engineering”, 2000

LITTLEWOOD 2010

Memorandum from Bev Littlewood to HSE, “Comments on ʻStep 3 C&I Assessment of the EDF and AREVA UK EPRʼ (Division 6 Assessment Report No. AR 09/038-P)”, January 2010

NEI 2009a Will Dalrymple, “Computer Bug”, in “Nuclear Engineering International”, August 2009

NEI 2009b John Bickel, “Digital I&C is Safe Enough”, in “Nuclear Engineering International”, November 2009

NW 2009 Articles in “Nucleonics Week”, July and November 2009

NW 2010 Articles in “Nucleonics Week”, June 2010

NF 2010 William Freebairn, “AREVA agrees to modify US-EPR after NRC raises I&C concerns”, in “Nuclear Fuel”, July 2010

NYT 2006 Nicola Clark, “The Airbus saga: Crossed wires and a multibillion-euro delay - Business - International Herald Tribune”, in the “New York Times”, December 2006.

PCSR 2009 AREVA and EDF, “UK EPR Preconstruction Safety Report”, June 2009 Update

RISKS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator, “The Risks Digest - Forum On Risks To The Public In Computers And Related Systems”, at http://catless.ncl.ac.uk/Risks/

S 2010 Letter to Thomas E. Sliva from David B. Matthews, “Status of U.S. EPR Design Certification Application Regarding Digital Instrumentation and Controls Review”, July 2010

SIEMENS 2010

Siemens Energy, “SPPA-T2000 Control Systems”, Documentation, 2010

SYMANTEC 2010

Nicolas Falliere, Liam O Murchu, and Eric Chien, “W32.Stuxnet Dossier”, Symantec, September 2010, Version 1.0

UK 2009 HSE Nuclear Directorate, “Step 3 Control and Instrumentation Assessment of the EDF and AREVA UK EPR”, 2009

24

UK 2009a HSE Nuclear Installations Inspectorate, "PCSR - Sub-Chapter 7.2 - General architecture of the Instrumentation & Control systems", UKEPR-0002-072 Issue 02, 2009

UK 2009b HSE Nuclear Installations Inspectorate, “UK EPR Control and Instrumentation (C&I) Architecture Regulatory Issue RI-UKEPR-002”, 2009

US 1997 US National Research Council, “Digital Instrumentation and Control Systems in Nuclear Power Plants: Safety and Reliability Issues”, National Academies 1997

US 1998 Gregory Slabodkin, “Software glitches leave Navy Smart Ship dead in the water”, in “Government Computer News”, 1998 at http://gcn.com/Articles/1998/07/13/Software-glitches-leave-Navy-Smart-Ship-dead-in-the-water.aspx

US 2009 NRC, “Diversity Strategies for Nuclear Power Plant Instrumentation and Control Systems”, 2009

VENCEL 2006 Th. Vencel, F. v. Schwartzenberg, “Biblis B mit digitaler Sicherheitsleittechnik”, Inernational Journal for Nuclear Power “atw”, 2006

WEBER 2008 P. Weber, “Second Generation of TELEPERM XS Applications Successful in Operation”, International Journal for Nuclear Power “atw”, 2008

25

Abbreviations and AcronymsASN! ! Autorité de Sûreté Nucléaire (French regulatory authority)BfS! ! Bundesamt für Strahlenschutz (German regulatory authority)C&I! ! Control and InstrumentationCCF! ! Common Cause FailureCNRA!! Committee on Nuclear Regulatory ActivitiesCSNI! ! Committee On The Safety Of Nuclear InstallationsEDF! ! Électricité de FranceEPR! ! European Pressurised Water ReactorEPRI! ! Electric Power Research InstituteHSE! ! Health and Safety Executive (UK regulatory authority)I&C! ! Instrumentation and ControlIAEA! ! International Atomic Energy AgencyKTA! ! Kerntechnischer AusschussKWU! ! Kraftwerk UnionMWe! ! MegaWatt ElectricalNPP! ! Nuclear Power PlantNRC ! ! Nuclear Regulatory Commision (US regulatory authority)OECD!! Organisation for Economic Co-operation and DevelopmentPAS! ! Process Automation SystemPC ! ! Personal ComputerPCSR!! Pre-construction Safety ReportSAS! ! Safety Automation SystemPFD! ! Probabiliyt of Failure on DemandSTUK!! Radiation and Nuclear Safety Authority (Finnish regulatory authority)TSC ! ! Technical Support ContractorTVO! ! Teollisuuden Voima Oyj (Finnish operator of NPPs)

Note that some countries use “I&C”, while others use “C&I”.

26