The five-point mod package development philosophy

The five principles of mod package development philsosophy

Mod package development is a daily reality for engineers working in the nuclear power industry. The earlier you understand the five-point structure that governs them, the quicker your skills and insight will increase.

Mod packages provide the means by which the nuclear plants can continually upgrade their systems and improve their performance by incorporating technological innovations. This drives down the cost of producing electricity over time. Mod package development is governed by five principles:

1. Purpose and intent

2. The mod package substance

3. Development boundaries (schedule, budget, and scope)

4. Mod package quality

5. Long-term consequences

Each will be described in order. The order is important.

FIRST, THE PURPOSE AND INTENT

The mod package process begins with intent and purpose. There is a problem that needs to be solved, or a goal that is desired to be achieved. This goal originates with a group of decision makers who have a project budget under their control. That goal is formally communicated in a contract or statement of work. The SOW might not call out the specifics of everything that needs to be done, but it will establish the project’s goals. The “client” is any person who commissions a design change package and has the money to pay for it.

Some of the most common project goals arise out of a desire to expand the plant’s current capabilities. Examples of this include adding features to control systems, consolidating older analog I&C systems with new digital ones, and upgrading the plant to increase its power output. Sometimes the plant is forced into initiating a design change because of component failures and maintenance issues. Normally, when components fail, they are replaced by a spare. But when spares run out due to obsolescence issues then a similar, though not identical, device must be installed in its place. This becomes an engineering activity.

Finally, new regulatory requirements can drive plant design changes. A notable example in recent history is the security rule issued on March 27, 2009 that consolidated a series of order issues immediately after the events of September 11, 2001 and created guidelines that made effective new legislative requirements that were added to the Atomic Energy Act in 2005. Following that were the FLEX and spent fuel pool instrumentation orders issued in the wake of the Fukushima disaster (EA-12-049 and EA-12-051).

These regulations contained new requirements and placed deadlines on the implementation. It was up to each plant to determine how it would specifically implement them. In all cases, the plant design changes began with goals that were controlled by, and implemented through, the mod package process.

SECOND, THE MOD PACKAGE ITSELF

The mod package is the full set of documentation representing the final design that will accomplish the project purpose. The mod package mediates between the client desire and the regulatory framework that controls the plant configuration. It does this by evaluating all aspects of the proposed design change to justify its acceptability for integration into the plant systems. The project goals are correctly translated into design requirements. The design requirements are then translated into design drawings, equipment procurement, implementation steps, long-term maintenance requirements, licensing basis updates, and so on.

As I’ve written elsewhere, the mod package summarizes the problem, describes the SSCs that are impacted along with their function, purpose, and safety classification, and finally details the solution and how it will impact the SSCs. Additionally, industry operating experience is investigated. All plants pool their lessons learned into a collective database which each plant can access. This way, historical performance of particular equipment can be investigated before a plant commits to using it. Additionally, particular issues that one plant may be having might have already been solved elsewhere. Those insights are gleaned and incorporated into the design change.

The mod package identifies existing operations procedures that need to be revised in light of the updated plant configuration. It also defines the testing requirements that will validate installation, confirm equipment functionality, and demonstrate final system performance before being returned to full-time service.

THIRD, DEFINING THE DEVELOPMENT BOUNDARIES

The traditional project management triangle plays into the the third aspect of mod package development. Projects are usually characterized by three primary constraints: scope, schedule, and budget. Schedule establishes the time limits involved in completing the project. The budget establishes how much the project is allowed to cost. Scope has several sub-components which combine to create the general limits on engineering. Scope involves regulations, procedures, codes, standards, and specifications. The design must fulfill the project goal — its scope — within the boundaries established by these documents.

First, the NRC requires that plant design changes be subject to design control measures, especially for safety-related SSCs. These measures assure that regulatory requirements, design and licensing basis information, and quality assurance requirements be correctly and consistently translated into design and implementation information. It also requires that:

Measures shall be established for the identification and control of design interfaces and for coordination among participating design organizations. These measures shall include the establishment of procedures among participating design organizations for the review, approval, release, distribution, and revision of documents involving design interfaces. [Ref. Appendix B of 10 CFR 50]

Any goal the plant owner decides to fulfill, then, must conform to these basic regulatory requirements established in Appendix B of 10 CFR 50. The mod package process applies these requirements to the engineering design to ensure it conforms to these regulations. It’s the plant procedures that define this process.

Procedures document the systematic process established for accomplishing mod package development. Every mod package must pull in multiple plant interfaces (e.g. maintenance, design, preventative maintenance, fire protection, licensing, implementation, configuration control, etc.). The mod package procedures explain how to properly communicate the design change with those various departments. The procedures establish design review meeting and design verification requirements, they point you to other forms that must be completed and submitted in order to properly engage the various departments, and they control the way that engineering documents are marked up, processed, and controlled. The procedures also establish which department or role is responsible for performing which mod-package-related task.

Codes are legal design requirements imposed by local, regional, or national authorities that are intended to establish minimum safety levels. Standards are recommended design practices developed by private organizations intended to capture years of best design practices while also balancing health and safety requirements. Sometimes the standards, as in the case of several nuclear-specific IEEE standards, contain the details that translate the sometimes vague or broad regulatory rules into specific requirements that, when met, will fulfill the regulatory intent.

Specifications can be existing or newly developed within the mod package process. Plants may have existing cable or equipment specifications, for example, which capture requirements established by their licensing basis. New cables or equipment might need to conform to those specifications, depending on the situation. Alternatively, the design change process might determine that a new equipment specification needs to be developed if a complex piece of machinery or software needs to be procured and installed to fulfill the design objective. The specification establishes the specific, detailed requirements and characteristics that equipment or software need to possess, and they are usually put out for bid by multiple vendors.

The procedures, codes, standards, and specifications all set forth the general requirements that the engineering team must adhere to. Together, they establish the boundaries of design development and place ultimate constraints on what kinds of design solutions are acceptable.

EVALUATING MOD PACKAGE QUALITY

The fourth point involves judging the success of the mod package. This is manifested in its quality. Quality is a measure of how well the mod package adhered to the constraints imposed in the third point.

Did it meet the schedule, or was it late? Meeting or exceeding the project schedule reflects positively, while missing deadlines reflects negatively.

Did it meet the budget, or were there overruns? Like schedule, coming in on or under budget reflects positively, while overrunning the budget reflects negatively.

Scope adherence can be more complex. A well-designed mod package that complies with all the relevant codes, standards, and procedures will have several things going for it.

A smooth implementation process that results in no re-designs from design-avoidable interferences is a positive indicator. This is especially important since construction costs tend to dwarf the engineering cost. Well-developed designs reduce construction costs because it is during the engineering phase where construction costs, as well as long-term maintenance and operations costs, are most easily realized. It can be beneficial to spend a little more on the design costs on the front end of a project because that can translate to significant savings on the construction end. Design errors or engineering oversights uncovered during construction can quickly lead to construction budget overruns.

Another positive indicator is an error-free configuration management update process that shows that all procedural requirements were adhered to. This is the case when no required data fields were inadvertently omitted when updating equipment databases, for example, or when all impacted departments got a chance to review the design and comment on it.

Design errors are usually the result of violating a code or design practice established in engineering standards, or by overlooking plant-specific information or history that would have cone to light if all the impacted departments had been correctly engaged. Finally, editorial mistakes like typographical errors detract from perceived value and are thought to be the result of violating human performance requirements usually prescribed in human performance procedures.

LONG TERM CONSEQUENCES

The fifth and final point involves the long-term consequences of implementing the modification.

Successful mod packages achieve the intended goal established in the statement of work. They result in lower operating costs, or they increase critical process margins, or reduce maintenance costs, or add new features that expand existing capabilities.

Mod-package failures are those that achieve the opposite. Poor designs increase maintenance costs over time because of unreliable equipment that was inadequately investigated. They might also increase operating costs because of poor designs that neglect standard industry practice, such as by creating periodic nuisance tripping that reveals itself only after being in operation for an extended amount of time. This could come about by not correctly factoring transformer inrush when sizing breakers or fuses.

Perhaps the most offensive of all is a mod package that, when installed, only fulfills the goal in part. This can happen when only some of the desired features were incorporated because of oversights during development that were only recognized too late, after too much money had already been spent, to go back and roll them in.

Any of these problems could lead to further expense taken in the form of preparing a follow-up mod package that is required to correct the problems created by the first. On the other hand, successful modifications produce benefits that compound on an annual basis and generate returns long after the modification has been implemented. The money saved, or the extra profit produced as a result of lower operating expenses achieved by a successful design, enables the plant to make other modifications in the future that produce similar results. This ultimately benefits the consumer by reducing the cost to produce electricity.

When the consumers are happy, everybody’s happy.

CONCLUSION

Successful mod package engineers are cognizant of this five-point governing structure and consciously incorporate its insight into their work. The consequences of doing so are packages that are implemented smoothly, followed by no long-term follow-up phone calls created by lingering problems. These goals should be the desire of every mod package engineer.

 

What do you think?