Method for determining reactor tripping

Abstract

To provide redundancy for paths for nuclear reactor trip detection and determination.SOLUTION: A nuclear reactor protection system includes: a plurality of functionally independent modules, each of the modules configured to receive a plurality of inputs from a nuclear reactor safety system, and logically determine a safety action based at least in part on the plurality of inputs; and one or more nuclear reactor safety actuators communicatively coupled to the plurality of functionally independent modules to receive the safety action determination based at least in part on the plurality of inputs.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to U.S. Provisional Patent Application No. 61 / 922,625, filed December 31, 2013, and U.S. Patent Application No. 14 / 198,891, filed March 6, 2014, the entire contents of both of which are incorporated herein by reference. [Technical background] SUMMARY This disclosure describes a nuclear reactor protection system and associated methods. [background] Reactor protection systems, and generally, reactor instrumentation and control (I&C) systems, provide automatic initiation signals, automatic and manual control signals, and monitoring indications to mitigate the consequences of fault conditions. For example, the I&C system provides protection against unsafe reactor operation during steady state and transient power operations. During normal operation, the I&C system measures various parameters and sends those signals to a control system. During abnormal operation and accident conditions, the I&C system sends signals to the reactor protection system, and in some cases to the reactor trip system (RTS) and engineered safety facility actuation system (ESFAS) of the reactor protection system, to initiate protective actions based on predefined set points. [overview] In a general implementation consistent with the present disclosure, a reactor protection system includes a plurality of functionally independent modules, each configured to receive a plurality of inputs from a reactor safety system and to logically determine a safety action based, at least in part, on the plurality of inputs, and one or more reactor safety actuators communicatively connected to the plurality of functionally independent modules to receive the safety action decision based, at least in part, on the plurality of inputs.

[0002] In a first aspect combinable with the overall implementation, each of the plurality of functionally independent modules provides protection against a single fault propagation to every other module of the plurality of functionally independent modules.

[0003] In a second aspect combinable with any of the previous aspects, the reactor safety system includes an Engineered Safety Facility Actuation System (ESFAS), where a plurality of functionally independent modules receive a plurality of ESFAS inputs and logically determine ESFAS component actuation based at least in part on the ESFAS inputs.

[0004] In a third aspect, which can be combined with any of the previous aspects, a plurality of functionally independent modules provide redundant ESFAS voting partitions. In a fourth aspect that can be combined with any of the previous aspects, a reactor safety system includes a reactor trip system (RTS), and a plurality of functionally independent modules receive a plurality of RTS inputs and logically determine RTS component operation based at least in part on the RTS inputs.

[0005] In a fifth aspect, combinable with any of the previous aspects, the multiple functionally independent modules provide redundant RTS voting partitions. In a sixth aspect combinable with any of the previous aspects, each of the plurality of functionally independent modules provides protection against single hardware fault propagation to any other of the plurality of functionally independent modules.

[0006] In a seventh aspect combinable with any of the preceding aspects, a plurality of functionally independent Each of the modules provides protection against a single software fault propagation to any other of the multiple functionally independent modules.

[0007] In an eighth aspect combinable with any of the previous aspects, each of the plurality of functionally independent modules provides protection against a single software-generated logic fault propagation to any other of the plurality of functionally independent modules.

[0008] In a ninth aspect, combinable with any of the previous aspects, the multiple functionally independent modules provide triple redundancy for a single pathway of reactor trip detection and decision making.

[0009] In a tenth aspect combinable with any of the previous aspects, the plurality of functionally independent modules includes a plurality of independent trip voting modules for each reactor trip component.

[0010] In an eleventh aspect, combinable with any of the previous aspects, the plurality of functionally independent modules logically determine reactor trips in isolation from all other modules of the plurality of modules dedicated to a particular trip component.

[0011] In a twelfth aspect combinable with any of the previous aspects, the plurality of functionally independent modules includes providing a plurality of independent ESFAS actuation voting modules for each ESF component.

[0012] In a thirteenth aspect combinable with any of the preceding aspects, the plurality of functionally independent modules logically determine ESFAS operation in isolation from all other modules of the plurality of modules dedicated to a particular ESF component.

[0013] In a fourteenth aspect combinable with any of the previous aspects, the plurality of functionally independent modules includes a plurality of safety function modules. In a second aspect combinable with any of the preceding aspects, the plurality of functionally independent modules includes a plurality of communication modules.

[0014] In a fifteenth aspect combinable with any of the previous aspects, the plurality of functionally independent modules includes a plurality of device interface modules. In a sixteenth aspect, combinable with any of the previous aspects, a plurality of functionally independent modules logically determine reactor trip in a single hierarchical voting scheme.

[0015] In a seventeenth aspect combinable with any of the previous aspects, a plurality of functionally independent modules logically determine reactor trip in a multi-hierarchical voting scheme. In an eighteenth aspect combinable with any of the previous aspects, the multi-tier voting scheme includes a two-tier voting scheme.

[0016] In a nineteenth aspect that can be combined with any of the previous aspects, a first tier of the two-tier voting scheme includes a majority voting scheme. In a twentieth aspect, combinable with any of the previous aspects, the majority voting scheme includes a two-thirds voting scheme.

[0017] In a twenty-first aspect, combinable with any of the previous aspects, the second tier of the two-tier voting scheme includes a non-majority voting scheme. In a twenty-second aspect, combinable with any of the previous aspects, the second tier includes a two-quarter voting scheme.

[0018] In another general implementation of the present disclosure, a method for determining a reactor trip includes receiving a plurality of inputs at a plurality of functionally independent modules of a reactor protection system from one of an Engineered Safety Facility Actuation System (ESFAS) or a Reactor Trip System (RTS), logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip determination based at least in part on the plurality of inputs, and actuating, based on the logical determination, one of an ESFAS component actuator or a reactor trip interrupter communicatively connected to the plurality of functionally independent modules.

[0019] The first aspect combinable with the overall implementation further includes limiting a single fault propagation by one of the plurality of functionally independent modules to any other of the plurality of functionally independent modules.

[0020] In a second aspect that can be combined with any of the previous aspects, the single fault includes at least one of a single hardware fault, a single software fault, or a single software-generated logic fault.

[0021] In a third aspect combinable with any of the previous aspects, logically determining, by a plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the input includes logically determining, by a plurality of functionally independent modules, an ESFAS safety operation or a reactor trip decision through triple redundant signal paths.

[0022] In a fourth aspect combinable with any of the previous aspects, the plurality of functionally independent modules provide at least one of redundant RTS voting units or redundant ESFAS voting units.

[0023] In a fifth aspect combinable with any of the previous aspects, logically determining, by a plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the inputs, includes logically determining, by a plurality of functionally independent modules, an ESFAS safety operation or a reactor trip decision through a plurality of independent trip voting modules for each reactor trip component.

[0024] In a sixth aspect combinable with any of the previous aspects, logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the input, includes logically determining, by a particular module of the plurality of functionally independent modules, an ESFAS safety operation or a reactor trip decision in isolation from all other modules of the plurality of modules.

[0025] In a seventh aspect combinable with any of the previous aspects, the plurality of functionally independent modules includes a plurality of independent ESFAS activation voting modules for each ESF component, and the method further includes logically determining ESFAS activation by a particular module of the plurality of functionally independent modules in isolation from all other modules of the plurality of modules dedicated to the particular ESF component.

[0026] In an eighth aspect combinable with any of the previous aspects, the plurality of functionally independent modules includes a plurality of safety function modules, a plurality of communication modules, and a plurality of device interface modules.

[0027] In a ninth aspect combinable with any of the preceding aspects, logically determining, by a plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the input, includes logically determining, by a plurality of functionally independent modules, an ESFAS safety operation or a reactor trip decision in a single hierarchical voting scheme.

[0028] In a tenth aspect combinable with any of the previous aspects, logically determining, by a plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the input includes logically determining, by a plurality of functionally independent modules, an ESFAS safety operation or a reactor trip decision in a multi-tier voting scheme.

[0029] In an eleventh aspect, combinable with any of the previous aspects, the multi-tier voting scheme includes a two-tier voting scheme. In a twelfth aspect combinable with any of the previous aspects, a first tier of the two-tier voting scheme includes a majority voting scheme.

[0030] In a thirteenth aspect combinable with any of the previous aspects, the majority voting scheme includes a two-thirds voting scheme. In a fourteenth aspect, combinable with any of the previous aspects, the second tier of the two-tier voting scheme includes a non-majority voting scheme.

[0031] In a fifteenth aspect, combinable with any of the previous aspects, the second tier includes a two-fourth voting scheme. In another general implementation consistent with the present disclosure, a nuclear reactor protection system includes multiple functionally independent modules that limit the transition of a single fault to a single module.

[0032] In another general implementation according to the present disclosure, a reactor protection system includes multiple functionally independent modules that include only three types of modules, thereby minimizing the number of replaceable units on the work line.

[0033] In another general implementation consistent with the present disclosure, a nuclear reactor protection system includes a number of functionally independent modules, including a communications module that determines a schedule for passing data across a data bus.

[0034] In another general implementation of the present disclosure, a reactor protection system includes a reactor trip system that defines a system architecture in which data is transmitted from the reactor trip system to a control room over a path that is exclusively related to safety functions, e.g., rather than post-accident monitoring functions.

[0035] In another general implementation consistent with the present disclosure, a reactor protection system includes a plurality of functionally independent modules, each of which is dedicated to a particular reactor trip interrupter among a plurality of reactor trip interrupters in the system.

[0036] In another general implementation consistent with the present disclosure, a reactor protection system includes a plurality of functionally independent modules, each of which makes reactor trip / no trip or ESFAS activation / no activation decisions completely independent of all of the other modules.

[0037] In another general implementation consistent with the present disclosure, a reactor protection system includes a plurality of functionally independent modules, each of which is dedicated to a particular ESFAS equipment actuator among a plurality of ESFAS equipment actuators in the system.

[0038] In another general implementation consistent with the present disclosure, a reactor protection apparatus includes means for receiving a plurality of inputs from a reactor safety system and logically determining a safe action based at least in part on the plurality of inputs, and means for receiving a safe action decision based at least in part on the plurality of inputs.

[0039] In a first aspect combinable with the overall implementation, a means for receiving a safe action decision receives a plurality of inputs from the reactor safety system and is communicatively connected to a means for logically determining a safe action.

[0040] In a second aspect, combinable with any of the previous aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action provides protection against single fault propagation within the apparatus.

[0041] In a third aspect combinable with any of the preceding aspects, the reactor safety system includes an engineered safety facility actuation system (ESFAS), and the means for receiving a plurality of inputs from the reactor safety system and logically determining a safety operation receives the plurality of ESFAS inputs and logically determines ESFAS component actuation based at least in part on the ESFAS inputs.

[0042] In a fourth aspect combinable with any of the previous aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action provides a redundant ESFAS voting unit.

[0043] In a fifth aspect combinable with any of the previous aspects, the reactor safety system includes a reactor trip system (RTS), and the means for logically determining a safety operation receives the multiple RTS inputs and logically determines RTS component operation based at least in part on the RTS inputs.

[0044] In a sixth aspect combinable with any of the previous aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action comprises redundant RTS voting segments.

[0045] In a seventh aspect combinable with any of the previous aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action provides protection against single hardware fault propagation within the apparatus.

[0046] In an eighth aspect combinable with any of the previous aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action provides protection against single software fault propagation within the apparatus.

[0047] In a ninth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe operation provides protection against a single software generated logic fault propagation within the apparatus.

[0048] In a tenth aspect combinable with any of the previous aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe operation includes a triple redundant signal path for reactor trip detection and determination.

[0049] In an eleventh aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe operation includes a plurality of independent trip voting modules for each reactor trip component.

[0050] In a twelfth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action independently determines a reactor trip for a particular reactor trip component.

[0051] In a thirteenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe operation comprises a plurality of independent ESFAS actuation voting modules for each ESF component.

[0052] In a fourteenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe operation independently determines ESFAS operation for a particular ESF component.

[0053] In a fifteenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe operation comprises a plurality of safety function modules.

[0054] In a sixteenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action comprises a plurality of communication modules.

[0055] In a seventeenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action includes a plurality of equipment interface modules.

[0056] In an eighteenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action logically determines to trip the reactor in a single hierarchical voting scheme.

[0057] In a nineteenth aspect combinable with any of the preceding aspects, the means for receiving a plurality of inputs from the reactor safety system and logically determining a safe action logically determines a reactor trip in a multi-tier voting scheme.

[0058] In a twentieth aspect combinable with any of the previous aspects, the multi-tier voting scheme comprises a two-tier voting scheme. In a twenty-first aspect combinable with any of the previous aspects, a first tier of the two-tier voting scheme comprises a majority voting scheme.

[0059] In a twenty-second aspect combinable with any of the previous aspects, the majority voting scheme comprises a two-thirds voting scheme. In a twenty-third aspect that can be combined with any of the previous aspects, the second tier of the two-tier voting scheme comprises a non-majority voting scheme.

[0060] In a twenty-fourth aspect, combinable with any of the previous aspects, the second tier comprises a two-quarter voting scheme. Various implementations of the reactor protection system according to the present disclosure may include one, some, or all of the following features. For example, the reactor protection system may mitigate common cause failures (CCFs) caused by software or software-generated logic errors that may disable and / or disable safety functions in the system. As another example, the reactor protection system may incorporate key attributes including independence, redundancy, determinism, multi-layered diversity, testability, and diagnostics. The reactor protection system may ensure that the reactor is maintained in a safe state. As another example, the reactor protection system may have increased simplicity through a symmetric architecture with functionality implemented in individual logic engines dedicated to specific functions. As yet another example, the reactor protection system may facilitate communication within the architecture based on a simple deterministic protocol and communicated via redundant paths.

[0061] Details of one or more implementations of the subject matter described herein are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. [Brief description of the drawings]

[0062] [Figure 1] 1 illustrates a block diagram of an example implementation of a system that includes multiple nuclear systems and an instrumentation and control (I&C) system. [Figure 2A] 1 illustrates a block diagram of a Modular Protection System (MPS) for an I&C system for a nuclear power system. [Figure 2B] 1 illustrates a block diagram of a Modular Protection System (MPS) for an I&C system for a nuclear power system. [Figure 3A] 1 illustrates a block diagram of a trip decision block of an MPS of an I&C system for a nuclear system. [Figure 3B] 1 illustrates a block diagram of an Engineered Safety Facility Actuation System (ESFAS) of an MPS of an I&C system for a nuclear system. [Figure 4A-4B]FIG. 1 illustrates an exemplary chart illustrating a multi-layered diversity strategy to mitigate software or software logic based common cause failures within an MPS that ensures the I&C system is able to perform its intended safety function. [Diagram 5] 1 illustrates a block diagram of a Safety Function Module (SFM) of an MPS of an I&C system for a nuclear system. [Figure 6] 1 illustrates a block diagram of a communications module (CM) of an MPS of an I&C system for a nuclear system. [Figure 7] 1 illustrates a block diagram of an Equipment Interface Module (EIM) of an MPS of an I&C system for a nuclear system. [Figure 8] 1 illustrates an exemplary embodiment of an enclosure for a reactor protection system that communicatively connects one or more SFMs, EIMs, and CMs. [Figure 9A] 1 illustrates block diagrams of a trip decision level interconnection, an RTS level interconnection, and an ESFAS level interconnection utilizing one or more of an SFM, a CM, and an EIM. [Figure 9B] 1 illustrates block diagrams of a trip decision level interconnection, an RTS level interconnection, and an ESFAS level interconnection utilizing one or more of an SFM, a CM, and an EIM. [Figure 9C] 1 illustrates block diagrams of a trip decision level interconnection, an RTS level interconnection, and an ESFAS level interconnection utilizing one or more of an SFM, a CM, and an EIM. [Figure 10] 1 illustrates a diversity analysis diagram for an MPS of an I&C system for a nuclear system. [Figure 11] 1 illustrates a block diagram of an exemplary separation of MPS blocks into four tiers of protection. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0063] [Detailed Description] FIG. 1 illustrates an exemplary implementation of a system 100 including multiple nuclear power systems 150 and a reactor instrumentation and control (I&C) system 135. In general, the I&C system 135 provides automatic initiation signals, automatic and manual control signals, and monitoring and indicator displays to prevent or mitigate the consequences of fault conditions in the system 100. The I&C system 135 provides normal reactor control and protection against unsafe reactor operation of the nuclear power systems 150 during steady-state and transient power operations. During normal operation, the instrumentation measures various process parameters and sends signals to a control system of the I&C system 135. During abnormal operation and accident conditions, the instrumentation sends signals to multiple parts of the I&C system 135 (e.g., a reactor trip system (RTS) 147 (e.g., for mitigating the effects of an accident) and an engineered safety facility activation system (ESFAS) 148, which are part of a modular protection system (MPS) 145) to initiate protective actions based on predefined set points.

[0064] 1, system 100 includes multiple nuclear systems 150 electrically connected to I&C system 135. Although only three nuclear systems 150 are shown in this example, there may be fewer or more (e.g., six, nine, twelve, or other number) systems 150 included within or connected to system 100. In one preferred implementation, there may be twelve nuclear systems 150 included within system 100, with one or more of the nuclear systems 150 including a modular light water reactor, as described further below.

[0065] For each nuclear system 150, and although not explicitly shown, the nuclear reactor core may provide heat that is utilized to boil water in a primary cooling loop (e.g., as in a boiling water reactor) or in a secondary cooling loop (e.g., as in a pressurized water reactor). Vaporized coolant, such as steam, may be used to drive one or more turbines, which convert the thermal potential energy into electrical energy. After condensation, the coolant is then returned to again remove more thermal energy from the nuclear reactor core. Nuclear system 150 is an example of any system that requires monitoring and protection functions to minimize the risks associated with failures in the system.

[0066] In a particular exemplary implementation of each reactor system 150, the core is located at the bottom of a cylindrical or capsule-shaped reactor vessel. The core contains a quantity of fissile material that produces a controlled reaction that may occur over a period of time, possibly several years or more. Although not explicitly shown in FIG. 1, control rods may be used to control the rate of fission within the core. The control rods may include silver, indium, cadmium, boron, cobalt, hafnium, dysprosium, gadolinium, samarium, erbium, and europium, or alloys and compounds thereof. However, these are only a few of the many possible control rod materials. In reactors designed with passive operating systems, the laws of physics are utilized to ensure that safe operation of the reactor is maintained for at least a predefined period of time, without operator intervention or supervision, during normal operation or even in emergency conditions.

[0067] In some implementations, a cylindrical or capsule-like containment vessel surrounds the reactor vessel and is partially or completely immersed in the reactor pool, e.g., below the water line, within the reactor bay. The volume between the reactor vessel and the containment vessel is partially or completely evacuated to reduce heat transfer from the reactor vessel to the reactor pool. However, in other implementations, the volume between the reactor vessel and the containment vessel may be at least partially filled with a gas and / or liquid that increases heat transfer between the reactor and the containment vessel. The containment vessel may rest on the skirt of the base of the reactor bay.

[0068] In certain implementations, the core is immersed in a liquid, such as water, which may contain boron or other additives, which rises up the channels after contacting the surface of the core. The coolant travels across the top of the heat exchanger and is drawn downward by convection along the inner wall of the reactor vessel, which in turn gives up heat to the heat exchanger. After reaching the bottom of the reactor vessel, contact with the core causes the coolant to heat up, and it rises up through the channels again.

[0069] A heat exchanger within a reactor vessel may exhibit any number of helical coils that wrap around at least a portion of a channel. In another implementation, a different number of helical coils may wrap around the channel in opposite directions, e.g., a first helical coil helically wraps in a counterclockwise direction while a second helical coil helically wraps in a clockwise direction. However, nothing prevents the use of differently configured and / or differently oriented heat exchangers, and implementations are not limited in this respect.

[0070] In Figure 1, normal operation of the reactor module proceeds as heated coolant rises through the channels and contacts the heat exchangers. After contacting the heat exchangers, the coolant sinks toward the bottom of the reactor vessel in a manner that induces an endothermic process. In the example of Figure 1, the coolant within the reactor vessel remains at a pressure above atmospheric pressure, thus allowing the coolant to maintain a high temperature without vaporizing (e.g., boiling).

[0071] As the temperature of the coolant in the heat exchanger increases, the coolant may begin to boil. Once the coolant in the heat exchanger begins to boil, the vaporized coolant, e.g., steam, may be used to drive one or more turbines, which convert the thermal potential energy of the steam into electrical energy. After being condensed, the coolant is returned to a location near the base of the heat exchanger.

[0072] 1, various performance parameters of the nuclear system may be monitored by sensors located at various locations within the nuclear system 150, such as the I&C system 135. The sensors within the nuclear system may measure system temperature, system pressure, primary and / or secondary coolant levels, and neutron flux. Signals indicative of these measurements may be reported over a communication channel external to the nuclear system to an interface panel of the I&C system 135.

[0073] The illustrated I&C system 135 generally includes a main control room 140, a module (or reactor) protection system (MPS) 145, and a non-safety module control system (MCS) 155. The main control room 140 includes a set of controls and instruments 141 for each nuclear system 150. Each set of controls and instruments 141 includes manual 1E controls 142, 1E instruments 143, and non-1E controls and instruments 144. In some aspects, "1E" can refer to regulatory requirements, such as the requirements defining the 1E scheme in section 3.7 of IEEE Standard 308-2001, approved by the Nuclear Regulatory Commission Regulatory Guide 1.32, which defines the safety classification of electrical equipment and systems essential for emergency reactor shutdown, containment isolation, core cooling, and containment and reactor heat removal, or otherwise essential in preventing significant releases of radioactive material into the environment. Typically, some controls and instruments (e.g., manual 1E controls 142 and 1E instruments 143) may be "1E" compliant, while other controls and instruments (e.g., non-1E controls and instruments 144) may not be "1E" compliant.

[0074] Non-1E controls and instruments 144 are in two-way communication with MCS 155. MCS 155 may provide control and monitoring of the non-safety portions of nuclear system 150. In general, MCS 155 suppresses operational transients, prevents unit trips, and re-establishes steady state unit operation, among other operations.

[0075] MPS 145 is in one-way communication with manual 1E controls 142 and 1E instruments 143, respectively, as shown in Figure 1. MPS 145 generally initiates safety actions to mitigate the consequences of design basis events. MPS 145 generally includes all the equipment (including hardware, software, and firmware) needed to initiate a reactor shutdown, from sensors to final actuation devices (power sources, sensors, signal conditioners, actuation circuits, logic, bypasses, control boards, interconnects, and actuation devices).

[0076] MPS 145 includes RTS 147 and ESFAS 148. RTS 147, in some aspects, includes four independent, separate groups (e.g., physical groupings of process channels having the same Class-1E electrical channel designation (A, B, C, or D), with separate and independent power sources and process instrumentation transmitters, and each of the groups being physically and electrically independent from the other groups) with independent measurement channels for monitoring plant parameters that may be utilized to generate a reactor trip. Each measurement channel trips when the parameter exceeds a predetermined set point. The coincidence logic of RTS 147 may be designed such that no single failure can prevent a reactor trip when needed, and no failure in a single measurement channel can generate an unnecessary reactor trip.

[0077] ESFAS 148, in some aspects, includes four independent isolation groups with independent measurement channels that monitor plant parameters that may be used to initiate operation of Engineered Safety Facility (ESF) equipment. Each measurement channel trips when the parameter exceeds a predetermined set point. The coincidence logic of ESFAS 148 may be designed such that no single failure can prevent safeguard operation when needed, and no single failure in a single measurement channel can produce unnecessary safeguard operation.

[0078] System 100 may include the specific application of the principles of defense in depth to the arrangement of instrumentation and control systems installed in a nuclear reactor to operate the reactor or to shut down and cool the reactor, such as the four tiers of protection as defined in NUREG / CR-6303. In particular, the four tiers are: control systems, reactor trip or scram systems, ESFAS, and monitoring and instrumentation systems (e.g., the slowest and most flexible tier of protection, a tier of protection that includes both Class 1E and non-Class 1E manual controls, monitors, and instruments required to operate equipment nominally assigned to the other three tiers).

[0079] The control system hierarchy typically includes MCS 155 (e.g., non-Class 1E manual or automatic control equipment) that periodically prevents reactor runaway into an unsafe operating regime and is typically used to operate the reactor within a safe power operating domain. Instruments, annunciators, and alarms may also be included in the control hierarchy. A reactor control system typically includes any equipment that meets specific regulations and / or requirements, e.g., requirements for a remote shutdown panel. Reactor control functions performed by the control system hierarchy are included in MCS 155. MCS 155 includes functions, for example, to keep system 100 within operating limits to avoid the need for a reactor trip or ESF operation.

[0080] The reactor trip system hierarchy typically includes RTS 147, e.g., safety equipment designed to rapidly reduce core reactions in response to an uncontrolled runaway. This hierarchy typically consists of instrumentation for detecting potential or actual runaway, equipment and processes for rapidly and fully inserting the reactor control rods, and may also include some chemical neutron moderation system (e.g., boron injection). As shown, the automatic reactor trip functions performed by the reactor trip hierarchy are included in MPS 145 (e.g., in RTS 147).

[0081] The ESFAS hierarchy typically includes an ESFAS module 148 that is part of the MPS 145. The ESFAS hierarchy implemented within the ESFAS module 148 typically includes safety equipment that removes heat or otherwise helps maintain the integrity of the three physical barriers to radioactive release (e.g., reactor fuel rod cladding, reactor vessel, and reactor containment). This hierarchy detects the need for and performs functions such as emergency reactor cooling, pressure relief or depressurization, isolation, and control of various support systems (e.g., emergency generators) or devices (valves, motors, pumps) required for the ESF equipment to operate.

[0082] The monitoring and instrumentation system hierarchy typically includes the main control room 140 and is in some respects the slowest and also most flexible hierarchy of protection. Like the other three hierarchy, human operators (e.g., of system 100) rely on accurate sensor information to perform their tasks, but can perform pre-specified logical operations to react to unexpected events given the information, time, and means. The monitoring and instruction hierarchy includes the class 1E and non-class 1E controls, monitors, and instruments required to operate the equipment nominally assigned to the other three hierarchy (e.g., through manual 1E controls 142, 1E instruments 143, and non-1E controls and instruments 144). The functions required by the monitoring and instrumentation system hierarchy are provided by manual controls, displays, and instruments in the main control room and include information from MCS 155 and MPS 145. Safety monitoring, manual reactor trip, and manual EFS activation functions are included in MPS 145. The MCS155 provides non-safety monitoring and manual control to maintain operating limits during normal plant operation.

[0083] In addition to including four tiers of protection, system 100 includes multiple levels of diversity. In particular, I&C diversity is the principle of using different technologies, logic, or algorithms to measure variables or provide actuation means to provide diverse ways of responding to potential plant conditions. Here, diversity is applied to the principle of instrumentation systems or actuation means that use different technologies, logic, or algorithms to sense different parameters to provide several ways of detecting and responding to critical events. Diversity is complementary to the principle of defense in depth, increasing the chances that a particular level or depth of protection will be actuated when needed. Generally, there are six diversity attributes: human diversity, design diversity, software diversity, functional diversity, signal diversity, and equipment diversity. As discussed in more detail in this disclosure, MPS 145 may incorporate six diversity attributes to mitigate the effects of common cause failures in MPS 145 (e.g., failures caused by software errors or software-generated logic that may negate the redundancy achieved by the hardware architecture).

[0084] Generally, human diversity is related to addressing human-generated errors (e.g., mistakes, misinterpretations, errors, configuration failures) throughout the system development lifecycle and is characterized by variances in the execution of lifecycle processes.

[0085] In general, design diversity is the use of different approaches, including software and hardware, to solve the same or similar problems. Software diversity is a special case of design diversity and is discussed separately because of its possible importance and its possible drawbacks. The rationale for design diversity is that different designs have different failure modes and are not susceptible to the same common effects.

[0086] Generally speaking, software diversity is the use of different software programs, designed and implemented by different software development groups with different key personnel, to achieve the same safety goal, for example, using two separately designed programs to determine when a nuclear reactor should be tripped.

[0087] In general, functional diversity refers to two systems (eg, subsystems within system 100) that perform different physical or logical functions, but the two systems may have overlapping safety effects.

[0088] In general, signal diversity is the use of different process parameters to trigger protective action, any one of which may independently indicate an abnormal condition even if the other parameters are not correctly detected.

[0089] In general, equipment diversity is the use of different equipment to perform a similar safety function (e.g., one of the processes or conditions essential to maintaining plant parameters within established tolerance limits for design basis events, which may be accomplished by the completion of all required protective actions by the RTS or ESF, or by the completion of functions that secondary support all required protective actions, or both). In this case, "different" may mean sufficiently different to significantly reduce vulnerability to common cause failures.

[0090] In some aspects, the MPS 145 may incorporate a combination of continuous (or partially continuous) self-tests and periodic monitoring tests. Such a testing strategy may ensure that all detectable faults are identified and notified to station personnel (e.g., through the main control room 140). The self-test function may provide a comprehensive diagnostic system that ensures that the system status is continuously (or partially) monitored. All detectable faults may be notified to station personnel and an indication of the effect of the fault may be provided to determine the overall status of the system. The self-test function maintains the independence of isolation groups and partitions. The self-test function ensures that the integrity of the system is maintained at all times.

[0091] In some aspects, each sub-module in MPS 145 (described in more detail below) may include a self-test function that provides high fault coverage designed to detect a single fault in the module. This can minimize the time required to detect a fault, providing benefits to safety and system availability. When the system is in normal operation, the self-test proceeds without affecting the performance of the safety functions, e.g., response time.

[0092] The self-test feature can detect most faults in both active and inactive logic (e.g., logic that is active only when a safety function is required to operate) and can avoid having faults go undetected. Fault detection and indication occurs at the MPS submodule level, allowing plant personnel to easily identify MPS submodules that need to be replaced.

[0093] A periodic on-line surveillance test capability may be built in to ensure that all functional tests and checks, calibration verification, and time response measurements are verified. The periodic surveillance test also verifies the continuous self-test functionality.

[0094] The self-test and periodic supervisory test functions in the MPS 145 may be designed for in-service testability commensurate with the safety functions being performed for all plant operating modes. Performance self-test and supervisory test do not require any interim test setup. The test functions may be inherent to the design of the system and may add minimal complexity to the safety function logic and data structures. A continuous indication of a bypass condition occurs when (1) a fault is detected by a self-test during normal plant operation or (2) some portion of the safety function is bypassed or intentionally disabled for testing. When the bypass condition is removed, the indication of bypass is removed. This may ensure that plant personnel can verify that the bypassed safety function has been properly returned to service.

[0095] Diagnostic data for the MPS 145 is provided to a Maintenance Work Station (MWS) for each isolation group and division. The MWS may be located in close proximity to the equipment to facilitate troubleshooting activities. The interface between the MPS and the MWS may be an optically isolated one-way diagnostic interface. All diagnostic data may be communicated by physically separate communication paths to ensure that diagnostic functions are independent of safety functions. Additionally, diagnostic data may be transmitted to a central historian for long term storage. This provides a means to perform historical analysis of system operation.

[0096] The diagnostic system may maintain a list of installed modules, which may be continually compared to the installed modules that are active in the system to prevent missing or incorrect modules from being installed.

[0097] All MPS safety data communications may be designed with error detection to enhance data integrity. Protocol features ensure that communications are robust and reliable with the ability to detect transmission failures. Similar data integrity features may be used to transfer diagnostic data.

[0098] 2A-2B illustrate a block diagram of a modular protection system (MPS) 200 of an I&C system for a nuclear power system 150. In some implementations, the MPS 200 may be similar to or identical to the MPS 145 shown in FIG. Generally, the illustrated MPS 200 includes four separate groups of sensors and detectors (e.g., sensors 202a-202d), four separate groups of signal conditioning and signal conditioners (e.g., signal conditioners 204a-204d), four separate groups of trip decisions (e.g., trip decisions 208a-208d), two sections of RTS votes and reactor trip interrupters (e.g., Section I RTS vote 214 and Section II RTS vote 216), and two sections of engineered safety facility actuation systems (ESFAS) votes and engineered safety facility (ESF) equipment (e.g., Section I ESFAS vote 212 and ESF equipment 224 and Section II ESFAS vote 218 and ESF equipment 226).

[0099] Generally, the sensors 202a-202d include process sensors responsible for measuring different process parameters, such as pressure, temperature, level, and neutron flux. As such, each process parameter of the nuclear system 150 is measured using a different sensor and processed by a different algorithm executed by a different logic engine. In some aspects, the neutron flux sensor is responsible for measuring the neutron flux from the core with shutdown conditions up to 120 percent of full power. Three types of neutron flux sensors may be used in the MPS 200, including source range, mid range, and power range.

[0100] Generally, the signal conditioners 204a-204d receive measurements from the sensors 202a-202d, process the measurements, and provide outputs 206a-206d. In some aspects, the interconnection of the sensors 202a-202d to the signal conditioners 204a-204d may be a dedicated copper wire or some other signal transmission method.

[0101] Each of the signal conditioners 204a-204d may be comprised of a number of input modules 270a-270n, shown in FIG. 3A (e.g., showing any number of modules depending on the number of sensor inputs), which are responsible for conditioning, measuring, filtering, and sampling the field inputs from the sensors 202a-202d. Each input module 270a-270n may be dedicated to a particular input type, such as, for example, a 24V or 48V digital input, a 4-20mA analog input, a 0-10V analog input, a resistive heat detector input, or a thermocouple input.

[0102] Each input module 270a-270n may consist of analog and digital circuitry. The analog circuitry is responsible for converting the analog voltage or current into a digital representation. The analog circuitry is also referred to as signal conditioning circuitry. The digital portion of each input module 270a-270n may be located in a logic engine. The logic engine performs all input module control, sample and hold filtering, integrity checks, self-tests, and digital filtering functions. Digital representations of the sensor outputs are communicated from the signal conditioners 204a-204d through outputs 206a-206d to the trip decision 208a-208d, in some examples using a serial interface.

[0103] 3A, the trip decisions 208a-208d generally receive sensor input values ​​in digital format via a serial interface from the signal conditioners 204a-204d, as described above. Each of the trip decisions 208a-208d consists of an independent safety function module (SFM) 272a-272n (described more fully with reference to FIG. 5), where a particular module implements one set of safety functions (e.g., a set may be a single safety function or multiple safety functions related to a particular process parameter). For example, a set of safety functions may consist of a group of functions related to a key variable, such as a high trip and a low trip from the same pressure input. Each SFM 272a-272n contains a unique logic engine dedicated to implementing one set of safety functions. This results in a gate-level implementation of each set of safety functions that is entirely different from all other sets of safety functions.

[0104] The sensor input values ​​(e.g., outputs 206a-206d) may be communicated via deterministic paths and provided to a particular SFM 272a-272n within each trip decision 208a-208d. These input values ​​may then be converted to engineering units to determine what safety function or set of safety functions is implemented on that particular SFM 272a-272n. The trip decisions 208a-208d provide these engineering unit values ​​to a control system, in some examples, via an isolated transmit-only fiber optic connection.

[0105] The SFM in each trip decision 208a-208d makes a reactor trip decision, if necessary, based on a predetermined set point and provides a trip request or no trip request signal to each RTS section (e.g., RTS votes 214 and 216 for sections I and II, respectively) over an isolated, and in some cases triple redundant, transmit-only serial connection. The SFM also makes an ESFAS activation decision, if necessary, based on a predetermined set point and provides an activation request or no activation request signal to each ESFAS section (e.g., ESFAS votes 212 and 218 for sections I and II, respectively) over an isolated, and in some cases triple redundant, transmit-only serial connection.

[0106] 3A-3B, for example, a particular trip decision 208a provides a trip request or no trip request signal to ESFAS vote 212 via output 274a and to ESFAS vote 218 via output 274b. Trip decision 208a provides a trip request or no trip request signal to RTS vote 214 via output 276a and to RTS vote 216 via output 276b. These outputs are also generally shown in FIG. 2A as outputs 210a-210d from trip decisions 208a-208d, respectively.

[0107] 3A, for example, a particular trip decision 208a provides a trip request or no trip request signal to monitoring and indication (M&I) outputs 278a and 278b (one per section) and to non-1E output 280. Outputs 278a and 278b provide process information to the MCS for non-safety control functions. Output 280 provides process information and trip status information to non-1E controllers and instruments 144.

[0108] Returning to Figure 2A, each RTS section (e.g., RTS vote 214 for section I and RTS vote 216 for section II) receives inputs from trip decisions 208a-d as described above by isolated and in some aspects redundant (e.g., dual, triple, or other) receive-only serial connections 210a-d. The trip inputs are combined in the RTS voting logic such that two or more reactor trip inputs from trip decisions 208a-d generate automatic reactor trip output signals on outputs 228a-d and 230a-d (as appropriate for each section) that activate trip coils for four of the eight reactor trip breakers (RTBs) (shown in Figure 2B) associated with the respective section. In other words, the RTS voting logic, in this exemplary implementation of MPS 200, works with a "two out of four" logic, meaning that if at least two of the four trip decisions 208a-d indicate that a reactor "trip" is necessary, then a trip signal is sent to each of the RTBs 264a-d and 266a-d. This breaker configuration allows for safe and easy online testing of MPS 200.

[0109] Manual trip 250a provides direct tripping of RTBs 266a-266d (for section I), and manual trip 250b provides direct tripping of RTBs 264a-264d (for section II) as well as input to automatic operation, manual trip 234 (for section I), and manual trip 236 (for section II) to ensure sequence is maintained.

[0110] As further shown, each RTB 264a-264d and each RTB 266a-266d includes a manual trip 250a and 250b as an input such that if both manual trips 250a and 250b (e.g., the manual trips for sections I and II, respectively) are activated, power input 260 will not be sent to power output 262 regardless of the state (e.g., tripped or untripped) of inputs 230a-230d and inputs 228a-228d.

[0111] The ESFAS votes and logic, in an exemplary implementation, are arranged such that no single failure can prevent safeguard operation when needed, and no single failure in the trip decision signals (e.g., 201a-210d) can produce unnecessary safeguard operation. The ESFAS system may provide both automatic and manual initiation of critical systems, such as emergency core cooling systems and decay heat removal systems.

[0112] Each ESFAS vote 212 / 218 receives inputs 201a-210d from trip decisions 208a-208d by an isolated, triple redundant, receive-only fiber optic (or other communication technique) connection. The actuation logic and voting occurs within the ESFAS vote 212 / 218. When the ESFAS vote 212 / 218 determines that actuation is required, the ESFAS vote 212 / 218 sends an actuation request signal to the ESFAS priority logic 220 / 222, respectively, which actuates the appropriate ESF equipment 224 and 226.

[0113] The illustrated implementation of the MPS 200 in Figures 2A-2B and 3A-3B ensures a high level of independence between key elements. This includes independence between the four separate groups of sensors and detectors 202a-202d, the four separate groups of trip decisions (labeled "a"-"d"), the two sections of the RTS 214 / 214 (section I and section II as mentioned), the two sections of the ESFAS circuitry 212 / 218 (section I and section II as mentioned), and the two sections of the ESF equipment 224 / 226 (section I and section II as mentioned). Based on the inputs to the SFMs (e.g., in the trip decisions 208a-208d), the MPS 200 independently implements a set of safety functions within each of the four separate groups. Safety function independence is maintained from the sensors 202a-202d to the trip decision outputs 210a-210d. This configuration, in some aspects, limits SFM failures to those based on the inputs of that module. This strategy can help limit the impact of common cause failures and increase signal diversity. This method of independence can also ensure that a failure within an independent safety function does not propagate to any of the other safety function modules. Furthermore, online replacement of a failed SFM ensures that the failure can be corrected with minimal impact, if any, to other modules.

[0114] Communication of safety function data within the illustrated MPS 200 is transmitted and received by triple modular, redundant, and independent optically isolated unidirectional communication paths. This communication scheme may ensure that, with the exception of inter-division voting, a safety function does not depend on any information or resources originating outside of the division to accomplish its safety function. Fault propagation between Class 1E divisions (e.g., Divisions I and II) is prevented by unidirectional isolation (e.g., optically isolated or otherwise) of the division trip signals.

[0115] The illustrated implementation of MPS 200 in Figures 2A-2B and 3A-3B further incorporates redundancy in several areas of the illustrated architecture. The redundancy within MPS 200 includes four separate groups of sensors and detectors (labeled "a" through "d"), trip decisions (labeled "a" through "d"), and two sections of RTS and ESFAS circuitry (section I and section II as mentioned). MPS 200 also uses two-fourths voting so that a single failure of an initiation signal will not prevent a reactor trip or ESF equipment operation from occurring when needed. Furthermore, a single failure of an initiation signal will not result in a false or unintended principle reactor trip or ESF equipment operation when not needed.

[0116] MPS200 also incorporates functional independence by implementing each set of safety functions used to mitigate specific transient events on independent SFMs with a unique logic engine for that particular set of safety functions.

[0117] In some aspects, MPS200 implements design techniques that provide a simple, reliable, and safe design for a nuclear reactor system. For example, MPS200 may be based on a symmetric architecture of four isolation groups and two partitions. Each of the four isolation groups may be functionally equivalent to the other isolation groups, and each of the two partitions may be functionally equivalent. As mentioned above, two-fourths voting may be the only voting strategy in the illustrated implementation. As another example, the logic of MPS200 may be implemented in a finite state machine (e.g., a collection of digital logic circuits that can be in one of a finite number of states, and that are in only one state at a time, called the current state, but can change from one state to another state when initiated by a set of triggering events or conditions, such as state transitions) dedicated to a particular safety function or group of safety functions. Thus, no kernel or operating system is required. As another example, communication within MPS200 may be based on a deterministic protocol, and all safety data is communicated by redundant communication paths. As another example, the versatility attributes of MPS 200 may be designed to be inherent to the architecture without the added complexity of an additional system based on an entirely different platform.

[0118] For example, Figures 4A-4B illustrate example charts 400 and 450, respectively, illustrating how a layered diversity strategy implemented within MPS 200 mitigates software-based or software logic-based common cause failures. Charts 400 and 450 illustrate how a layered diversity strategy implemented within MPS 200 can eliminate concerns about software-based or software logic-based CCFs within an MPS (e.g., MPS 200). In these examples, the transient event is a loss of feedwater for a nuclear system. As illustrated, two different process parameters A1 and A2 are measured (e.g., via sensors 202a-202d). A1 is a temperature parameter as illustrated, while A2 is pressure as illustrated.

[0119] Different process measurements A1 and A2 are input to two different safety function algorithms, i.e., (A1) high temperature and (A2) high pressure, as shown. Each of the two safety function algorithms is located on a separate and independent SFM in a separate group. The safety function algorithms may be implemented using two different sets of programmable digital hardware (A / C and B / D) that are divided into four separate groups (A, B, C, D) and two partitions as shown with MPS 200. For example, here the two safety functions comprise a single set of safety functions. Each set (e.g., of the two safety function algorithms) may be based on a different technology.

[0120] Design diversity is also built into the process, since each set of programmable digital hardware may be designed by a different design team using a different set of design tools. As an example, the safety functions may be implemented in a microprocessor. In this example, the safety functions may be evaluated in a sequential manner, which may in some aspects introduce a dependency of one safety function (e.g., A2) on another safety function (e.g., A1) due to the sequential operation of the processing loop. As another example, the safety functions may be implemented in a state-based field programmable gate array (FPGA). In this example, each safety function may be evaluated independently of all other safety functions. This latter example may ensure increased independence by removing any dependency of the processing of one safety function on another safety function.

[0121] The multi-layered diversity for the loss of water supply transient example provides protection against CCFs that disable protective action by limiting the software CCF to one set (A / C) of a specific safety function (A1). In some aspects, the software CCF is limited to a specific safety function based on the functional independence between the two safety functions and the process measurements that the safety function algorithm uses as inputs. In some aspects, the software CCF is limited to one set of specific safety functions by incorporating different programmable hardware, design teams, and design tools for each set. With the CCF limited to one set of specific safety functions, the transient is mitigated by the other set (B / D) of that safety function (A1) or both sets (A / C and B / D) of a second safety function (A2).

[0122] For example, as shown in Figure 4A, the output of the safety function for A1 indicating that protective action should be taken by all four isolation groups (A, B, C, D) (e.g., indicated by check marks) will result in the initiation of a protective action (e.g., indicated by "trip"). As shown in Figure 4B, if there are CCFs in two isolation groups (A and C) for safety function A1, as well as two groups in a single partition, a positive indication of protective action in the other isolation groups (B and D) will still result in enough votes to initiate a protective action (in the two-fourth scheme described above). Additionally, the CCFs in groups A and C for safety function A1 do not propagate to safety function A2 because the evaluations for each SFM are independent.

[0123] Figure 5 illustrates a block diagram of a Safety Function Module (SFM) 500 of an MPS of an I&C system for a nuclear system. Figure 6 illustrates a block diagram of a Communications Module (CM) 600 of an MPS of an I&C system for a nuclear system. Figure 7 illustrates a block diagram of an Equipment Interface Module (EIM) 700 of an MPS of an I&C system for a nuclear system. Figure 8 (discussed below) illustrates communication paths within an enclosure (e.g., a mechanical structure that interconnects one or more SFMs 500, CMs 600, and EIMs 700). Generally, the illustrated modules 500, 600, and 700, interconnected within a housing (illustrated by housing 800 and described below), implement the safety functions of MPS 200 and comprise separate group level modules (e.g., signal conditioners 204a-d, trip decisions 208a-d), RTS level modules (e.g., RTS voting 214 / 216), and ESFAS level modules (e.g., ESFAS voting 212 / 218). In some aspects, having three types of modules (500, 600, and 700) can minimize the number of replaceable units in a work line, thereby minimizing obsolescence. Furthermore, these modules (500, 600, and 700) may be functionally independent such that a single failure in any individual module (500, 600, and 700) does not propagate to other modules or other safety functions. Furthermore, the combination of modules (500, 600, and 700) implemented in Figures 8A-8C can result in a discrete, deterministic safety signal path.

[0124] In some aspects, the modules (500, 600, and 700) may have one or more characteristics that at least partially define their functional independence. For example, each of the modules may be fully autonomous with respect to each other module in the overall system / architecture (e.g., in MPS 200). As another example, each of the modules may perform a particular intended safety function autonomously with respect to each other module in the overall system / architecture. As yet another example, each of the modules may include dedicated logic that is specific to the module's particular intended safety function. Thus, each functionally independent module may not depend on logic or functionality from any other module to perform its particular intended safety function.

[0125] 5, SFM 500, as shown, processes sensor inputs or data from other SFMs to make reactor trip and / or ESF activation decisions for the isolation group to which the particular SFM is assigned (e.g., isolation group A, B, C, or D). SFM 500 can be used in two separate configurations: (1) sensor signal conditioning and reactor trip and / or EFS activation with safety data bus communication, and (2) safety data bus communication with reactor trip and / or EFS activation decisions.

[0126] As shown, the SFM 500 generally includes an input block 504, a functional logic block 512, and communication blocks 514, 516, and 518. Each input block 504 (four are shown in FIG. 5) consists of a signal conditioning circuit 506, an analog-to-digital (A / D) converter 508, and a serial interface 510. Each input block 504 is communicatively connected to a sensor 502 (which may be the same as or similar to sensors 202a-d, for example). As shown, an individual SFM 500 can handle up to four input blocks 504 (in the illustrated exemplary embodiment). The input types may be any combination of analog and digital (e.g., 4-20 mA, 10-50 mA, 0-10V) that the SFM 500 would need to make trip or ESF activation decisions, including generating authorizations and interlocks.

[0127] Function logic block 512 is the programmable portion of SFM 500 that converts the output from serial interface 510 of input block 504 (if used) into engineering units. Function logic block 512 may also make trip and / or ESF activation decisions based on the output of input block 504 (e.g., based on sensor measurements from sensor 502) and / or information from the safety data bus. Function logic block 512 may also generate permits and control interlocks. As shown, function logic block 512 is comprised of multiple deterministic logic engines that utilize information available from input block 504 and / or the safety data bus to make trip or ESF activation decisions.

[0128] Set points and other tunable information utilized by the function logic block 512 may be stored in non-volatile memory (e.g., on the SFM 500). This may allow changes without modifying the underlying logic. Furthermore, to implement function diversity, signal diversity, and software diversity, the primary and backup functions used to mitigate AOO or PA may not be on the same SFM 500. Thus, by using a dedicated SFM 500 for a function or group of functions, and by ensuring that the primary and backup functions are on separate modules 500, the impact of software CCF is limited due to the uniqueness of the logic and algorithms on each module 500.

[0129] Communications block 514 / 516 / 518 consists of five separate communication ports (e.g., three safety data ports labeled 514, one port labeled 516, and one port labeled 518). Each port is functionally independent and is designated as either a monitoring and instruction (M / I) bus (e.g., block 516), a maintenance workstation (MWS) bus (e.g., block 518), or a safety bus (e.g., block 514). Although each safety data bus 514 may communicate the same data, each communication port is asynchronous and the ports package and transmit data differently by using different, independent and unique communication engines. For example, one safety data bus 514 may transmit, for example, ten packets of data in sequential order (e.g., 1, 2, ..., 10), while another safety bus 514 transmits the same ten packets in reverse order (e.g., 10, 9, ..., 1), and a third safety bus 514 transmits the even packets first followed by the odd packets (e.g., 2, 4, ..., 10, 1, 3, ..., 9). This triple modular redundancy and diversity not only allows for communication error detection, but also limits the communicating CCFs to a particular bus without affecting the ability of the RTS or ESFAS to make the correct trip and / or operation decisions.

[0130] Referring to FIG. 6, the CM600 is an I&M controller for nuclear systems (e.g., MPS200). The CM 600 provides independent and redundant communication between other modules of the MPS, such as the SFM 500 and the EIM 700, within the separation group level interconnect, the RTS level interconnect, and the ESFAS level interconnect of the MPS of the C system. For example, the CM 600 may be a scheduler for the pipeline through which data passes within the MPS and such passage of data. For any particular channel, the CM 600 may control the manipulation / passage of data within that channel. In the illustrated implementation of the CM 600, there are three types of blocks: restricted communication block (RCB) 604, communication scheduler 606, and communication block 608 / 610.

[0131] The RCB 604 consists of four communication ports as shown. In some aspects, each port is configured to be a different unidirectional (e.g., receive only or transmit only) path. In some implementations, as with the illustrated CM 600, information received from or transmitted by a particular RCB 604 passes through an opto-isolator 602. In some cases, the opto-isolator 602 can help ensure that data from any particular trip decision is isolated from data from other trip decisions, thereby ensuring independent redundancy.

[0132] The communications scheduler 606 is responsible for moving data from the communications block 608 / 610 to the RCB 604 or from the RCB 604 to the communications block 608 / 610. In some aspects, the communications engine 606 comprises programmable logic, such as an FPGA, a microprocessor, or other discrete logic that is programmed to schedule communications between the described interconnects.

[0133] Communications block 608 / 610 consists of four separate communications ports (e.g., three safety data ports labeled 608 and one port labeled 610). Each port may be functionally independent and is designated as a monitoring and instruction (M / I) bus (e.g., block 610) or a safety data bus (e.g., block 608). In some aspects, M / I bus 610 may collect information from all modules in the MPS (e.g., modules 500, 600, and 700), including the status of each of such modules, and transmit that information to a "historian" station (e.g., a computing system dedicated to historical data of the MPS).

[0134] Although each secure data bus 608 may communicate the same data, each communication port packages and transmits the data differently, as described above with reference to bus 514. Depending on the application of the communication module, the four communication blocks 608 / 610 may be configured in any combination of one-way and two-way paths.

[0135] 7, the EIM 700 generally provides an interface to each component within the nuclear system within the RTS and / or ESFAS level system for trip decisions to be voted for and component level actuations and operations to occur. As shown, the EIM 700 includes an output block 720, an instrument feedback block 718, an 1E manual input 716, a non-1E manual input 714, a voting engine 722, a priority logic block 721, an instrument control block 723, and a communication block 724 / 726 / 728. Generally, the EIM 700 may perform voting, or in some cases double voting (e.g., 2 / 3 vote for communication and 2 / 4 vote for trip signal) based on the trip signal to ensure that a single component failure does not propagate within the channel level interconnection of the MPS of the I&C system for the nuclear system (e.g., MPS 200), the RTS level interconnection, and the ESFAS level interconnection. The EIM 700 may perform priority assignments for automated signals from the votes 722 , the manual actuation / 1E inputs 716 , and the non-1E inputs 714 .

[0136] The output block 720 includes up to three independent output switches, or more in some examples, that may be used in an external circuit and connected to an electrical load 702 (e.g., an actuator), as shown. In some aspects, this allows the EIM 700 to directly control a single component or provide trigger signals for multiple components. For example, the output block 720 energizes a relay, which starts various pumps and opens multiple valves. Each output block 720 may also include the ability to self-test and perform load continuity checks.

[0137] The instrument feedback block 718 may consist of multiple (e.g., up to three or more in some examples) feedback inputs 704 from instruments as shown. The feedback inputs 704 may include, for example, valve position (e.g., fully open, fully closed), interrupter status (e.g., closed / open), or other feedback from other components. The instrument feedback 704 may be used in the voting instrument control block 723 as discussed below.

[0138] The 1E manual input block 716 may provide multiple (e.g., up to two or in some examples more) manual input signals 706. This portion of the EIM 700 may be dedicated to manual inputs and is utilized in the priority logic block 721.

[0139] A number of input signals 708 are connected to a non-1E input block 714 via an electrical isolation interface 712. This electrical isolation interface 712 allows the use of non-1E signals for input to a priority logic block 721.

[0140] The voting engine 722 receives trip decision inputs from the communication block 724. The result of the vote provides an activation or deactivation signal to the priority logic block 721 for an automatic activation signal. In some aspects, the voting engine 722 may implement a voting scheme, or in some cases a double voting scheme, to ensure that a failure of a single component in the MPS does not propagate. For example, in some aspects, the voting engine 722 receives trip decisions in the communication block 724. Each communication block 724 may receive trip decisions (e.g., trip or no trip) from four channels or separation groups (e.g., channels A-D as described above). Within the voting engine 722, in some aspects, there may be three "A" trip decisions, three "B" trip decisions, three "C" trip decisions, and three "D" trip decisions. Thus, the voting engine 722 may perform a two-thirds decision for each of the four channels or separation groups. For example, if at least two of the three "A" channels provide valid communication of a trip (e.g., indicating that communication of a trip decision is valid), the voting engine 722 may, at least initially, communicate that a trip exists on channel "A", whereas if only one of the three "A" channels indicates a trip, the voting engine 722 may determine that a trip does not exist on channel "A".

[0141] The voting engine 722 may implement a double voting scheme, as described above, to further ensure that faults do not propagate throughout the MPS structure. For example, following the two-thirds communication decision described above, the voting engine 722 may also perform a two-quarters trip decision to determine if a trip actually occurred (as opposed to a fault indicating a false trip, for example). For example, the outputs of four voting blocks (e.g., two of three voting logic gates) in the voting engine 722 that make two of three decisions may be sent to another voting block (e.g., two of four voting logic gates) that makes two of four decisions. If at least two of the four outputs from the first hierarchical voting block (e.g., two of three blocks) indicate a trip, the voting engine 722 may determine that a trip has occurred (and that EFS equipment, such as the load 702, should be activated), otherwise the voting engine 722 may determine that no trip actually occurred at all.

[0142] The priority logic block receives inputs from the voting block 722, the 1E manual input block 716, and the non-1E manual input block 714. The priority logic block 721 then determines what to command the appliance control module to do based on all of the inputs.

[0143] The instrument control block receives commands from the priority logic module and performs appropriate actions or operations on the components via the output block 720. The instrument control block receives feedback from the instruments via the instrument feedback block 718 for instrument control purposes.

[0144] The equipment control block 722, the priority logic block 721, and the voting block 722 each provide status information to a maintenance work station (MWS) bus (e.g., block 728). The communications blocks 724 / 726 / 728 consist of five separate communications ports (e.g., three secure data ports labeled 724, one port labeled 726, and one port labeled 728). Each port may be functionally independent and is designated as either a monitoring and instruction (M / I) bus (e.g., block 726), a maintenance work station (MWS) bus (e.g., block 728), or a secure data bus (e.g., block 724).

[0145] 8 illustrates an exemplary embodiment of a reactor protection system (e.g., MPS 145) enclosure 800 that communicatively connects one or more SFMs 500, EIMs 700, and CMs 600. The figure presents an example of three SFMs 500 or EIMs 700 connected to four CMs 600 within the enclosure 800. In this example, five data bus paths are shown. For example, there are three safety data ports 802, labeled X, Y, and Z, respectively. There is one data bus path 804 labeled M / I. There is one data bus path 804 labeled MWS. Each data bus path 802 / 804 may be functionally and electrically independent from all other data bus paths 802 / 804 within the enclosure 800 in this example.

[0146] In this illustrated embodiment, each of the CMs 600 may include a master for one of the data bus paths 802 / 804. As shown, the master 808 of the X data bus path 802 is part of the CM 600 for safety data X. The master 810 of the Y data path 802 is a CM 600 for safety data Y. The master 812 of the Z data path 802 is a CM 600 for safety data Z. Finally, as shown in this example, the master 814 for the M / I data path 804 is a CM 600 for M / I. Also in this example, there is a MWS master 816 that is the master for the MWS data path 806, which is separately connected (e.g., as a maintenance workstation). The maintenance workstation (MWS master) 816 may be isolated for normal operation of the equipment by a hardwire switch.

[0147] 9A-9C illustrate block diagrams of isolation group level interconnection, RTS level interconnection, and ESAFAS level interconnection utilizing one or more of SFM 500, CM 600, and EIM 700. In general, modules SFM 500, CM 600, and EIM 700 may be arranged within MPS 200 as functionally independent modules (e.g., assemblies of interconnected components that constitute identifiable devices, instruments, or equipment elements, have definable performance characteristics that allow them to be disconnected, removed as a unit, and replaced with a spare, and tested as a unit) that provide protection against propagation of a single fault (e.g., hardware, software, or other) to adjacent or other safety functions. Modules may provide up to triple redundancy in some implementations for trip detection and decision making. Modules may also be arranged to provide redundant RTS and ESFAS voting segments, as described above. In some implementations, the module may provide multiple independent trip voting modules for each trip component (eg, breaker, sensor, or other).

[0148] In some cases, a module provides an RTS vote, while in other cases, a module provides an ESFAS vote. With respect to the independence of each module, each module may make a decision for a particular trip, separate from all other modules dedicated to a particular trip component, to activate or not activate an RTS / ESFAS trip. In some implementations, the decision to enable communication of the trip decision may be made by majority vote (e.g., two-thirds). In some implementations, the decision may be made in a dual voting scheme, where communication of the trip decision is enabled by majority vote (e.g., two-thirds) and a secondary trip decision vote is by a less than majority vote (e.g., two-quarters).

[0149] 9A, an exemplary separation group level interconnect 900 is illustrated. The illustrated channel level interconnect 900 includes channel sensor inputs 902, SFMs 500 that receive the inputs 902, and CMs 600 that communicate outputs 904 through 920. As shown, each SFM 500 in the channel level interconnect 900 may include four inputs 902, or in some cases more, in any combination of analog and digital, to implement a single function or set of functions. Each input 902 may be unique to a particular SFM 500 (e.g., a channel A pressurizer pressure signal is a direct input to only one SFM 500). Input data may be available on all four data buses, along with status information (e.g., alarms, logic decisions, module status).

[0150] The safety buses may be functionally independent, with each safety bus using a master-slave protocol, with the master being the CM 600. Although the blocks within the SFMs operate synchronously, communication between modules may be asynchronous. When the CM 600 for a bus requests information from a particular SFM 500, the SFM 500 may respond to the bus by broadcasting. The advantage of broadcasting is that, for example, if the SFM 500 labeled "1" has information (e.g., enable signal, sensor input value) that the SFM 500 labeled "2" needs, SFM 500 "2" can listen and get the needed information.

[0151] In addition to the three safety data buses (e.g., labeled "X," "Y," and "Z"), there is a fourth illustrated communication bus for monitoring and instruction (M / I). The master of the M / I bus may be a CM 600 dedicated to providing M / I data to safety gateways and non-safety control systems. Unlike the CMs 600 for the three safety data buses (e.g., buses X, Y, and Z), the M / I CM 600 may be able to listen to broadcast information on all three safety buses.

[0152] In some implementations, the restricted communication blocks (RCBs) of the CM 600 may have various point-to-point configurations. In an isolated group level interconnect 900, all four communication ports on the RCB may be configured for transmit only. Data from each safety data bus CM 600 (e.g., CM 600 labeled X, Y, and Z) may be configured for transmit only. may be sent to each section (e.g., sections I and II) of the RTS and ESFAS. Data from the M / I CM 600 (e.g., outputs 916-920) may be sent to the safety gateway and non-safety control systems.

[0153] Outputs 904-914 may be provided, for example, to an RTS level interconnect and an ESFAS level interconnect (discussed below). For example, as shown, outputs 904, 908, and 912 may be provided to an ESFAS level interconnect, while outputs 906, 910, and 914 may be provided to an RTS level interconnect. Although only one isolation group level interconnect 900 is shown in FIG. 9A, there may be multiple interconnects 900 in the MPS structure.

[0154] 9B, an exemplary RTS level interconnection is shown divided by partitions. The RTS level interconnection includes RTS partitions I and II (e.g., RTS polls 214 and 216) as shown. Each partition (214 and 216) shown includes four CMs 600 and four EIMs 700. For each partition, each of the three safety data buses (labeled X, Y, and Z) may receive trip or no trip decisions from all four isolation groups (e.g., having isolation groups labeled with the same numerical value, i.e., A1 and B1), shown as inputs 962-972. A fourth CM 600 may be provided to transmit data (as outputs 974-976) to non-safety control systems and safety gateways, as shown.

[0155] Each communication port on the RCB for each safety bus CM 600 may be configured for "receive only" and may be optically isolated (as described above). The M / I CM 600 may have all ports on the RCB configured for "transmit only".

[0156] In some implementations, the trip decisions for each safety data bus from all isolation groups are available to each of the four EIMs 700. The EIMs 700 may use all three safety buses (labeled X, Y, and Z) to ensure there are no false trips of breakers due to communication errors. When at least two of the four isolation groups (inputs 962-972) indicate a trip condition, the reactor trip breaker is opened. Each EIM 700 may be dedicated to the undervoltage relay and shunt trip coil of the reactor trip breaker, for example. In addition to automatic actuation, the EIMs 600 will have inputs for manual section level reactor trip 978, breaker feedback, and ESFAS feedback.

[0157] The EIM 600 outputs (labeled 980a-980d for Division I and 982a-982d for Division II) may be connected to inputs for trip coils for a reactor trip breaker (RTB) (shown in FIG. 2B) associated with the particular division.

[0158] 9C, an exemplary ESFAS level interconnection is shown divided by partitions. The ESFAS level interconnection includes ESFAS partitions I and II (e.g., ESFAS voting 212 and 218) as shown. Each partition (212 and 218) shown includes four CMs 600 and four EIMs 700. For each partition, each of the three safety data buses (labeled X, Y, and Z) receives ESF actuation decisions, labeled as inputs 962-972, from all isolation groups (in this example, the four isolation groups labeled D).

[0159] Each communication port on the RCB for each safety data bus CM 600 (labeled X, Y, and Z) may be configured for "receive only" and may be optically isolated (as described above). The M / I CM 600 has all ports on the RCB configured for "transmit only" and may be optically isolated.

[0160] In some implementations, ESF activation decisions from all isolation groups are available to the EIM 700 on all three safety data buses (labeled X, Y, and Z). For example, the EIM 700 may use all three safety data buses to ensure that there are no equipment malfunctions caused by communication errors. When at least two of the four isolation groups indicate a need for ESF activation (e.g., on inputs 962-972), a safety function may be initiated through output 990 (connected to ESF equipment 224 and 226 based on the classification as shown in FIG. 3B). In some aspects, each EIM 700 may be dedicated to an individual component (e.g., a single ESF component).

[0161] In addition to automatic initiation, each EIM 700 can control the components using manual inputs 992. Additionally, each EIM 700 may also receive non-1E control inputs 994. The non-1E control inputs 994 (also shown as inputs 282 in FIG. 3B) may be provided to the EIM 700 for the non-1E to control the 1E safety ESF components based on the output of the EIM. Component feedback (e.g., limit switches), voting decisions, and other available information (e.g., alarms) may be sent from the M / I CM 600 as outputs 974-976.

[0162] Figure 10 illustrates a diversity analysis diagram for an I&C system 135 for a nuclear system. For purposes of diversity analysis, the blocks identified in Figure 10 show a level of detail that simplifies system testing. The blocks were selected to represent a physical subset of equipment and software whose internal failures can be assumed not to propagate to other blocks based on their attributes.

[0163] As shown, the blocks in the diagram of Fig. 10 illustrate an I&C system, in this example, I&C system 135. Block 1002 represents non-1E monitoring and indication equipment, blocks 1004a / b represent 1E monitoring and indication I and II, respectively, and blocks 1006a / b represent safety blocks I and II, respectively. Block 1006a includes isolation groups A and C, RTS I, and ESFAS I, while block 1006b includes isolation groups B and D, RTS II, and ESFAS II. Block 1008 represents the MCS. As shown, connecting lines with arrows indicate communication between the blocks.

[0164] One of the objectives for the four tiers is diversity. For example, an MPS may meet a single-failure criterion that requires that the MPS perform all safety functions required for a design-basis event in the presence of (1) any single detectable failure in the safety system simultaneously with all identifiable but undetectable failures, (2) all failures resulting from a single failure, and (3) all failures and erroneous system behaviors that result in or are caused by a design-basis event that requires the safety function. This requirement may provide increased reliability, but does not preclude the system from being vulnerable to common cause failures (CCFs). For any design, there may be dependencies (e.g., coupling factors) that distinguish CCFs from multiple independent failures. This results in two basic forms of preventing common cause failures in a system: either the causative effects are reduced or the system's ability to withstand these effects is increased.

[0165] These two forms of implementation can be implemented with the six attributes mentioned above, namely, design diversity, equipment diversity, function diversity, human diversity, signal diversity, and software diversity. The application of these attributes is examined with respect to each block illustrated in FIG. 10 and the attributes between the blocks illustrated in FIG. 10. Attributes in Blocks As illustrated with reference to the previous figures and as will be described, the separation groups A, B, C, and D as well as the two divisions RTS and ESFAS are grouped according to the programmable technology on which they are based. The safety blocks I and II together constitute a modular protection system (MPS) (e.g. MPS200).

[0166] With regard to signal diversity, for a given transient event, there may be at least two safety functions, each based on a measured variable of a different physical effect (e.g. pressure, level, temperature, neutron flux). The loss of one safety function does not prevent the block from identifying the need for a protective action.

[0167] With regard to software diversity, based on its inputs, each safety function module (SFM 500) is dedicated to a safety function or group of safety functions. As a result, each SFM has a unique algorithm / logic. Each communication module (CM 600) sends the same packets of information in a different order which may require each communication engine (608 / 610) in the CM to have a different algorithm. Each equipment interface module (EIM 700) may be dedicated to a single component and may provide a unique algorithm / logic.

[0168] 1E monitoring and indication may be accomplished using two sections: a video display unit (VDU) and physical switches. Each section of the 1E monitoring and indication (M / I) may be block 1004a / b. For design diversity, each section of the M / I may provide the operator with plant status information on a digital display and also have a manual switch to manually initiate any protective action at the section level. For signal diversity, the operator may have all the measured variables utilized by the MPS and determine if tripping and / or EFS activation is required. Although not as fast, the operator may have multiple measured variables of different physical effects to make the same determination as the MPS. [Block diversity attributes] Regarding human diversity, the software of safety blocks I and 1E M / II may be designed by one design team, and safety blocks II and 1E M / II may be designed by a different design team. Furthermore, an independent verification and validation team may review the work of each design team to ensure the correctness of the designs. The aforementioned design teams are similarly different from the design teams assigned to the modular control system (MCS) and non-1E M / I.

[0169] Design diversity is the use of different approaches, including both software and hardware, to solve the same or similar problems. To limit the likelihood and consequences of CCF, safety block I 1004a and 1E M / II block 1006a may use different programmable technology than safety block II and 1E M / III. MCS and non-1E M / I may also have different programmable technology. Along with other attributes discussed below, different hardware designs may have different failure modes, thus reducing the likelihood of a CCF affecting more than one block. For example, except for the M / I block, the blocks may be physically separated in different rooms. This is intended to further reduce coupling factors that may create a situation where multiple components are involved in a CCF event.

[0170] Software diversity is a subset of design diversity and may also include the use of different programs designed and implemented by different development groups with different key personnel to achieve the same safety goal. Due to the design diversity discussed above, different design teams may use different design tools, and thus the tools may not introduce the same failure modes.

[0171] Functional diversity may be introduced by having different purposes and functions among the blocks. Safety blocks I and II form the MPS. These blocks may initiate reactor trips if operational limits are exceeded and may initiate ESFs to mitigate postulated accidents. The M / I blocks may allow an operator to monitor and control both safety and non-safety systems. The operator may maintain the plant within operational limits or initiate required protective actions. The MCS provides automatic control of the system to maintain the plant within operational limits, including limiting certain operational transients.

[0172] Between the blocks, signal diversity may be provided by having automatic and manual means of operating equipment and protection actions. The MCS and non-1E M / I provide equipment level control, while the 1E M / I blocks provide section level control.

[0173] Equipment diversity is the use of different equipment to perform similar safety functions. Initiation of the protective action can be by operator action using a switch or can be performed automatically by Safety Block I or II. Between Safety Block I and II, different programmable technologies may be used, which may require different internal sub-components and different manufacturing methods.

[0174] Another analysis guideline for the four tiers is the type of system failure. A type 1 failure is a failure that fails to take protective action for a plant transient initiated by a control system error due to interactions between the tiers of protection. Usually, this is related to the failure of a common sensor or signal source. Some of the plant parameters monitored by the MPS are provided to the MCS for normal plant control. As mentioned above, instead of having one signal source, all four separate groups and both ESFAS and RTS divisions provide information through isolated unidirectional communication. This may allow the MCS to use a different method (e.g., central signal selection) to select which redundant and independent signal source to use.

[0175] Type 2 failures are failures that may not directly result in a transient change and may not cause protective equipment to respond to plant transient changes because the failure is undetected. Using attributes in and between safety blocks I and II, there may be enough diversity to prevent an undetected failure or CCF from affecting more than one block. With only one of the two blocks required to automatically initiate a protective action, type 2 failures may be mitigated by the MPS (safety blocks I and II) without further systems.

[0176] A type 3 failure is one in which the primary sensor relied upon to detect the design basis event produces an abnormal reading. Signal diversity may exist within the safety block by providing at least two safety functions, each based on a different measurement parameter, for any transient event. If all four separate groups of sensors for a given safety function provide abnormal readings, there may be two possible adverse scenarios for a type 3 failure: 1) the abnormal reading indicates that no trip or ESF activation is required when the limit is actually exceeded, and 2) the abnormal reading indicates that a trip or ESF activation is required even if the limit is not exceeded (e.g., a false trip or ESF activation). In the first scenario, a type 3 failure occurring simultaneously with a CCF within a safety block may not prevent the initiation of a required protective action. As previously mentioned, signal diversity may allow separate safety functions to be available to mitigate the transient event. The CCF within the MPS is assumed to be limited to one of the two safety blocks and to prevent the initiation of a protective action or to prevent initiation due to a false indication. For example, as discussed above, two-quarter coincidence logic may be used for all trips and ESF operations where two of the four isolation groups indicate the need for a trip or ESF operation for the unaffected safety functions on the unaffected safety blocks, providing a positive indication to the operator of the action to be taken.

[0177] In the second scenario, a Type 3 fault in a safety block coincident with a CCF results in a false trip or ESF actuation, and the 1E M / I blocks then show one block positive and one block positive with a false indication of successful actuation, or one block positive and one block with no indication of actuation. In either case, evaluating the false actuation and correcting it may be lengthy for the operator, but the ability to realign components as necessary is provided by both 1E and non-1E controlled devices that would not be affected by the same CCF.

[0178] Another analysis guideline is the hierarchy requirement. The four conceptual hierarchies of protection are split into separate blocks (e.g., safety blocks I and II, 1E M / II and II) as well as combined in some blocks (e.g., RTS and ESFAS) to provide blocks that represent levels of detail that simplify system inspection. In some aspects, the separation groups, RTS, and ESFAS are grouped into safety blocks according to the programmable technology on which they are based. For example, each half of the MPS (e.g., two of the four separation groups, one of the two divisions of ESFAS, and one of the two divisions of RTS) or one safety block may have sufficient diversity attributes. Different design teams (human diversity) utilize different programmable digital hardware based on different programmable technologies (design and equipment diversity), and different programmable technologies require the use of different design tools (software diversity). The M / I hierarchy may be split into separate blocks as well. The 1E M / I blocks may be partitioned to specify that the 1E M / I blocks have similar diversity attributes as the safety blocks. How selected blocks fit into the four tiers of protection is illustrated in FIG. 11, which shows a diagram 1100.

[0179] Another analysis guideline is the evaluation method. The selected block should be considered as a "black box" so that any contingency that needs to be assumed will produce the most detrimental outcome when analyzed according to the output signal guideline (discussed below). In some aspects, the failure of the system to operate may not be the worst case failure, especially when analyzing the time required to identify and respond to a condition caused by a CCF in the automated safety system. The blocks will be evaluated based on the hardware CCF and the software CCF. For each CCF, the block may be evaluated as having three possible outputs that may produce the most detrimental outcome: 1) remaining in a failed state with a false indication or no operation when required, 2) false initiation of the function with an indication of successful operation, and 3) false initiation of the function without an indication of successful operation. The EIM in any of the safety blocks may not be considered vulnerable to the software CCF. For example, the EIM may be a priority logic module dedicated to a single ESF component or reactor trip interrupter and an interface with manual and automatic controls. The use of a finite state machine may enable exhaustive testing of functionality, including all possible inputs, device states, and state machine outputs. Based on its testability, EIM versatility attributes, and being dedicated to a single component, the EIM may be simple enough that consideration of a software-based or software logic-based CCF is not required.

[0180] Another analysis guideline is the assumed common cause failure of the blocks. The 1E M / I block includes a combination of a video display unit (digital hardware) and a manual control (non-digital hardware). The VDU may be designed for indication only and has no ability to control equipment. The manual control in each 1E M / I block 1004a / b provides the operator with the ability to initiate at the section level any protective actions that are automatically performed by the safety block I or II. With indication and manual control being different hardware in some instances (e.g. digital vs. open / close contact switches), the CCF may be assumed to affect one or the other, but not both. For both software and hardware CCFs, a failed condition results in the operator display of one section indicating an incorrect safe operating state or a manual switch failure of one section. The VDU may have little or no control capability and therefore may not provide an incorrect operation. However, in the case of a software CCF, the VDU may provide an incorrect indication of successful operation or provide an inaccurate plant state, requiring the operator to initiate an incorrect protective action.

[0181] Except for the EIM, modules in the safety block are assumed to have software CCFs. Due to the diversity attribute in the safety block, software CCFs may be limited to CMs or functions on the SFM. Software CCFs in the safety block that prevent the SFM from making the proper trip decision may be mitigated by the equipment, signal, and software diversity in that block. For each transient event, the primary and backup safety functions required to mitigate the event may be implemented on separate safety functions using different logic / algorithms based on measured parameters of different physical effects. With a triple module redundancy implementation and each data bus transmitting the same information in a different way, a CM with software CCF may not erroneously initiate or prevent the initiation of a protective action. As a result, the most damaging scenario may be a software CCF in the SFM resulting in erroneous activation of the ESFAS function.

[0182] A hardware CCF in a safety block may be assumed to be a complete failure of the block to detect and initiate the required protective action. A hardware CCF resulting in an erroneous activation of an ESF function may have the same effect as an erroneous activation caused by a software CCF and thus may also not be considered.

[0183] Non-1E M / I includes controls for safety and non-safety equipment. The VDUs for non-1E are different from the VDUs used by 1E M / I. Since non-1E M / I is used for normal day-to-day operation, any erroneous operation induced by software or hardware CCFs in non-1E M / I subsystems (e.g., turbine control, feedwater control) may be immediately identifiable and may be mitigated by MPS (Safety Blocks I and II) if operational limits are exceeded. Contingencies for non-1E are 1) failure-holding conditions with erroneous operation of a subsystem component with and without indication of successful operation, and 2) failure-holding conditions with indication of successful operation when no equipment is actually operated.

[0184] The MCS encompasses non-safety systems that are relied upon to maintain day-to-day plant operation within operational limits, including limiting certain operational transients. Thus, any failure of a subsystem (e.g., rod control) can be immediately detected by the operator. As with non-1E M / I, the assumed software and hardware CCFs for the MCS result in 1) failed conditions having erroneous operation of a subsystem component with and without an indication of successful operation, and 2) failed conditions that provide an indication of successful operation when no equipment is actually operated.

[0185] Another analytical guideline is the use of identical hardware and software modules, where the diversity between blocks provides a basis for not considering blocks that are identical. Based on this, the envisaged CCF may be limited to a single block.

[0186] Another analysis guideline is the influence of other blocks. All blocks are assumed to function correctly in response to correct or incorrect inputs. Each block is considered independent and unaffected by the assumed CCFs in other blocks.

[0187] Another analysis guideline is the output signals. In some aspects, the I&C architecture may prevent errors from propagating backwards to the output of a previous block. All information from safety blocks I and II to the 1E M / I may be sent through an optically isolated transmit-only communication engine (shown in CM600). Signals from the 1E M / I to the safety blocks may be open / close contacts from manual switches, whose positions or contact states cannot be changed by the CCF in the safety blocks. Communication information between the safety blocks may be data sent from isolation groups A and C to ESFAS and RTS division II, and from isolation groups B and D to ESFAS and RTS division I. The four isolation groups are independent and redundant. However, for the purposes of illustration in FIG. 10, the isolation groups are grouped into safety blocks according to the programmable technology they use. Communication from isolation groups to any division of RTS and ESFAS, as well as communication between the safety blocks and the 1E M / I, may be through an optically isolated transmit-only communication engine. Non-safety inputs to the safety block may be to an ESFAS EIM and may be limited to isolated open / close contacts.

[0188] All inputs from the safety block may be from optically isolated transmit-only communication engines. This may prevent any errors in the 1E M / I from propagating backwards to the safety block.

[0189] Another analysis guideline is diversity for predicted operational events. A single CCF or type 2 failure related to a transient event may not prevent the MPS from performing its safety function. Safety blocks I and II, which together constitute the MPS, may be selected to limit the CCF to one block. Traditionally, nuclear power plants have relied on diversified actuation systems (DAS) or anticipatory transition without scram (ATWS) to provide diverse ways to initiate functions if the MPS is disabled by a CCF. However, in the illustrated MPS design, there may be enough diversity in the system to initiate a safety function even with a single CCF. Here, the MPS is divided into safety blocks I and II (e.g., 1006a / b). The assumed software or hardware CCF will be limited to one safety block. Each block uses a different design team (human diversity) utilizing different programmable digital hardware based on different programmable technologies (design and equipment diversity), and different programmable technologies may require the use of different design tools (software diversity). Within each block, there may be at least two safety functions based on measurands of different physical effects implemented on separate SFMs. All logic may be implemented in finite state machines and all safety data may be communicated in a deterministic manner. Due to these attributes, even a type 3 fault associated with a CCF may not prevent the MPS from initiating the required protective action.

[0190] Another analytical guideline is accident diversity: Similar to AOO, postulated accidents related to CCF errors in the MPS may not prevent the MPS from performing its safety function.

[0191] Another analysis guideline is manual operator action. Manual section level actuation of protective actions performed by the MPS may be provided to the operator. Manual component level control is provided to the operator using non-1E M / I if permitted by the 1E M / I.

[0192] Particular implementations of the subject matter have been described. Other implementations, alternatives, and modifications of the described implementations are within the scope of the following claims, as will be apparent to those skilled in the art. For example, the actions recited in the claims may be performed in a different order and still achieve desirable results. Thus, the foregoing description of exemplary implementations does not define or limit the disclosure. Other modifications, substitutions, and alternatives are also possible without departing from the spirit and scope of the disclosure.

Claims

1. 1. A method for determining a nuclear reactor trip, comprising: receiving a plurality of inputs at a plurality of functionally independent modules of a reactor protection system from one of an engineered safety facility actuation system (ESFAS) or a reactor trip system (RTS); logically determining, by said plurality of functionally independent modules, one of an ESFAS safe operation or a reactor trip decision based at least in part on said plurality of inputs; activating one of an ESFAS component actuator or a reactor trip interrupter communicatively connected to the plurality of functionally independent modules based on the logical determination; Equipped with At least some of the plurality of functionally independent modules include a plurality of input modules between different sensors and different safety function modules; each of the plurality of input modules independently conditions an input from a connected sensor and transmits a conditioned output to a connected safety function module; the plurality of functionally independent modules comprises a plurality of independent, ESFAS-activated voting modules for each ESF component; The method further comprises: logically determining said ESFAS operation by a particular module of said plurality of functionally independent modules in isolation from all other modules of said plurality of functionally independent modules dedicated to a particular ESF component.

2. The method of claim 1 , further comprising limiting propagation of a single fault by one of the plurality of functionally independent modules to any other of the plurality of functionally independent modules.

3. The method of claim 2 , wherein the single fault comprises at least one of a single hardware fault, a single software fault, or a single software-generated logic fault.

4. 2. The method of claim 1, wherein logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the plurality of inputs comprises logically determining, by the plurality of functionally independent modules, the ESFAS safety operation or the reactor trip decision through triple redundant signal paths.

5. The method of claim 1 , wherein the plurality of functionally independent modules provide at least one of redundant RTS voting partitions or redundant ESFAS voting partitions.

6. 2. The method of claim 1, wherein logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the plurality of inputs comprises logically determining, by the plurality of functionally independent modules, the ESFAS safety operation or the reactor trip decision through a plurality of independent trip voting modules for each reactor trip component.

7. 7. The method of claim 6, wherein logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the plurality of inputs, comprises logically determining, by a particular module of the plurality of functionally independent modules, the ESFAS safety operation or the reactor trip decision in isolation from all other modules of the plurality of functionally independent modules.

8. The method of claim 1 , wherein the plurality of functionally independent modules comprises a plurality of safety function modules, a plurality of communication modules, and a plurality of device interface modules.

9. 2. The method of claim 1, wherein logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the plurality of inputs comprises logically determining, by the plurality of functionally independent modules, the ESFAS safety operation or the reactor trip decision in a single hierarchical voting scheme.

10. 2. The method of claim 1, wherein logically determining, by the plurality of functionally independent modules, one of an ESFAS safety operation or a reactor trip decision based at least in part on the plurality of inputs comprises logically determining, by the plurality of functionally independent modules, the ESFAS safety operation or the reactor trip decision in a multi-tier voting scheme.

11. The method of claim 10 , wherein the multi-tier voting scheme comprises a two-tier voting scheme.

12. The method of claim 11 , wherein a first tier of the two-tier voting scheme comprises a majority voting scheme.

13. The method of claim 12 , wherein the majority voting scheme comprises a two-thirds voting scheme.

14. 12. The method of claim 11, wherein a second tier of the two-tier voting scheme comprises a non-majority voting scheme.

15. The method of claim 14 , wherein the second tier comprises a 2 / 4 voting scheme.

Images