INEEL/EXT-05-02643

Revision 1

Software Requirements
Specification
Verifiable Fuel Cycle Simulation (VISION)
Model

AFCI Economic Benefits and Systems

Analysis Teams

November 2005

Idaho National Engineering and Environmental Laboratory

Bechtel BWXT Idaho, LLC
This page blank.
 INEEL/EXT-05-02643, Rev. 1

Software Requirements Specification

Verifiable Fuel Cycle Simulation (VISION) Model

AFCI Economic Benefits and Systems Analysis Team

November 2005

Idaho National Laboratory

Idaho Falls, Idaho 83415
Prepared for the
U.S. Department of Energy
Office of Nuclear Energy, Science, and Technology
Under DOE Idaho Operations Office
Contract DE-AC07-05ID14517 (INL)
Contract W-31-109-ENG-38 (ANL)
Contract DE-AC04-94AL85000 (SNL)
 ACKNOWLEDGMENTS

The AFCI modeling team acknowledges the efforts of those who contributed to this
document: David E. Shropshire, INL; Kent A. Williams, ORNL; W. Brent Boore,
WSRC; J. D. Smith, SNL ; Brent W. Dixon, INL; Mary-Lou Dunzik-Gougar, INL/ISU;
Jake J. Jacobson, INL; William H. West, INL; Steven J. Piet, INL; Gretchen E. Matthern,
INL; Robert N. Hill, ANL; Abdellatif M. Yacout, ANL; Erich Schneider, LANL; Len
Malczynski, SNL; Christopher T. Lewis, ISU; Chris Juchau, ISU.
 Table of Contents

Acronyms............................................................................................................................ 1
Introduction......................................................................................................................... 4
Need, Scope, and Purpose For VISION.............................................................................. 4
Scope of VISION............................................................................................................ 4
Purpose of VISION......................................................................................................... 4
Users of VISION............................................................................................................. 6
High-Level Functionality.................................................................................................... 6
Assumptions...................................................................................................................... 15
Requirements .................................................................................................................... 15
Flow Model Variables................................................................................................... 16
Economic Analysis Functionality ................................................................................. 18
Analysis of Estimates or Measures ............................................................................... 20
General Model Architecture Elements.......................................................................... 22
Hardware/Software ....................................................................................................... 28
Constraints .................................................................................................................... 29
Software Quality ............................................................................................................... 30
Quality Documentation................................................................................................. 30
Performance Testing ..................................................................................................... 30
Verification and Validation........................................................................................... 30
Reference Documents ....................................................................................................... 30
Acronyms
AFC Advanced Fuel Cycle
AFCI Advanced Fuel Cycle Initiative
ANL Argonne National Laboratory
BCC Base Construction Cost
CH Contact Handled
COA Code of Accounts
D&D Decontamination and Decommissioning
DDS Design description for software
DOE U.S. Department of Energy
EMWG Economic Modeling Working Group
FICA Federal Insurance Contribution Act
FOAK First-of-a-Kind
HLW High-level Waste
IAEA International Atomic Energy Agency
IDC Interest During Construction
IMF Inert Matrix Fuel
INL Idaho National Laboratory
ISU Idaho State University
LANL Los Almos National Laboratory
LFR Lead-Cooled Fast Reactor
LLW Low-level Waste
LUEC Levelized Unit of Electricity Cost
LWR Light Water Reactor
MOX Mixed Oxide Fuel
MRS Monitored Retrievable Storage
MSR Molten Salt Reactor
NOAK Nth-Of-A-Kind
NRC Nuclear Regulatory Commission
O&M Operations and Maintenance
OCRWM Office of Civilian Radioactive Waste Management
ORNL Oak Ridge National Laboratory
R&D Research and Development
RD&D Research, Development, and Demonstration
RH Remote Handled
RTM Requirements traceability matrix
SCMP Software configuration management plan
SCWR Supercritical-Water-Cooled Reactor
SFR Sodium-Cooled-Fast Reactor
SMP Software management plan
SNF Spent Nuclear Fuel
SNL Sandia National Laboratory
SQAP Software quality assurance plan
SRS Software Requirements Specification
STP Software test plan
SWU Separative Work Unit
TCIC Total Capital Investment Cost
TOC Total Overnight Cost
TRU Transuranic
TSLCC Total System Life Cycle Cost
UREX Uranium Extraction Process
V&V Verification and Validation
VHTR Very-High Temperature Reactor
VISION Verifiable Fuel Cycle Simulation Model
WBS Work Breakdown Structure

-1-
WIT What-It-Takes
WSRC Westinghouse Savannah River Company
WU Weapons Useable
YMP Yucca Mountain Project

-2-
This page blank.

-3-
Introduction
The purpose of this Software Requirements Specification (SRS) is to define the top-level
requirements for a Verifiable Fuel Cycle Simulation Model (VISION) of an Advanced
Fuel Cycle (AFC). This simulation application is intended to serve as a broad systems
analysis and study tool applicable to work conducted as part of the AFCI (including cost
estimates) and Generation IV reactor development studies. This is a “living document”
that will be modified over the course of the execution of this work element, but with
configuration control of the INL work package manager for AFCI Integrated Model
Development, in consultation with the INL work package manager for AFCI Economic
Benefits.

Need, Scope, and Purpose For VISION

There is a lack of validated and verified estimating models to support fuel cycle cost
analysis. Previous cost studies have failed to provide a complete economic accounting of
all the relevant fuel cycle costs (e.g., omission of D&D costs, refurbishment, or waste
forms) that comprise the overall life cycle costs of a facility. Such “partial” studies can
result in misleading conclusions. The goal of the VISION model is to establish a credible
systems basis for an AFC and to create a reference source for fuel cycle unit costs.

Scope of VISION
VISION will dynamically simulate an AFC from cradle to grave, including mining of raw
material to disposition of waste after electricity generation. It models the nuclear fuel
cycle and accounts for, or accommodates changes in process capability, including
transition from "design and construct to startup to equilibrium to final D&D" states as
well as material, capital, and operating costs. To accomplish this cradle to grave analysis,
VISION should simulate distinct fuel cycle activities, called modules, which represent
the various front-end fuel cycle, back-end fuel cycle, waste disposition, and
transportation functions.

Purpose of VISION
VISION is intended to be the AFCI system analysis simulation tool of the entire fuel
cycle (including cost estimates) to assist in evaluating and improving major fuel cycle
options against all four AFCI programmatic objectives – waste management,
proliferation resistance, energy recovery, and systematic fuel management (economics,
safety, at-reactor storage).

VISION is NOT intended to actually manage the fuel cycle. For example, there is no
intent to track each fuel assembly from each reactor, as might be required for actual fuel
management.

VISION will build upon the functionality contained in the Dynamic Model of Nuclear
Development (DYMOND) originally developed for the Generation IV Fuel Cycle Cross
Cut group. The VISION model will incorporate the DYMOND model and add (1)
isotopic flow control and decay, (2) additional recipes from transmutation analyses such
as VHTR with recycling, (3) simplified models for fuel separation and fabrication, (4)

-4-
cost calculations, (5) uranium resources model, and (6) increased flexibility in transitions
and combinations of individual fuel cycle technologies.

The VISION model will be used to:

• Quickly assess and evaluate, with reasonable accuracy, relative economic
differences in fuel cycle strategies and timing.
• Understand issues and opportunities for keeping nuclear power an economically
competitive option;
• Create an in-depth basis for understanding fuel cycle costs, their sensitivities and
uncertainty; and
• Develop economic tools to evaluate creative solutions to make the nuclear fuel
cycle cost competitive.
• Estimate a levelized cost of electricity.
• Compare strategies – once-thru, single-pass, multi-pass thermal, thermal/fast
symbiotic, breeder.
• Compare technologies – IMF vs. MOX, separation processing, reactor type.
• Improve, but not optimize, scenarios.
• Simulate feedback looks, e.g., the conversion of a UOX-capable to MOX-capable
reactor could be controlled by an algorithm involving the accumulation of
available MOX, the cost of the conversion, the downtime for the conversion, cost
of new reactors, etc.
• Explore new ideas vs. established lines of thinking.
• Conduct qualitative and quantitative comparisons of alternative fuel cycles with
respect to:
o resource requirements,
o reactor types and mix,
o sequencing and timing,
o interim waste storage,
o energy recovery,
o proliferation resistance,
o safety
o waste streams, and
o repository capacity and performance requirements.

Typical, but by no means all, of the questions that may be answered with VISION
include:
• What does it take to defer or reduce number of repositories? When? Cost?
• How to reduce Pu inventory?
• How to reduce transportation costs and numbers?
• Should the US offer more fuel services?
• How much Pu may be made or destroyed from a scenario? When? How much in
storage?

-5-
Users of VISION
There are two major groups of users anticipated for the VISION model. The user group
will have a direct bearing on the implementation of some of the requirements described in
the requirements section of this document.

Group 1: Composed of analysts, scientists, System Engineers, and model developers

internal to the AFCI project within the Department of Energy (DOE) and affiliated
National Laboratories or AFCI contractors. These users will be responsible for
developing the model, conducting theoretical “what-if” scenarios to test assumptions and
further refine alternatives, assessing the reliability and robustness of model results, and
making suggested changes to the model based on their studies. In general this class of
users will have access to internal versions of the model for testing, analysis and
experimentation.

Group 2: Composed of analysts, scientists, System Engineers, and Department of Energy

employees external to the AFCI project. These users will use a compiled or “locked”
version of the model to conduct analysis and “what-if” scenarios within the published
functionality of the model. These users will have access to approved and published
versions of the software that have been through an established quality assurance process
that verifies and validates the model.

VISION is not intended for use by people unfamiliar with advanced fuel cycles, the
issues, terminology, and basic interrelationships.

High-Level Functionality
VISION will dynamically model an AFC from cradle to grave, including mining of raw
material to disposition of waste after electricity generation. To accomplish this cradle to
grave analysis, VISION should simulate distinct fuel cycle activities, called modules,
which represent the various front-end fuel cycle, back-end fuel cycle, waste disposition,
and transportation functions.

Each type of fuel cycle facility or activity is referred to as a module (see Figure 1). A
module represents a specific fuel cycle function that is separate but dependent on other
fuel cycle activities (e.g., the enrichment module is influenced by the enrichment required
by the fuel manufactured in the fuel fabrication module). The modules are assembled in
various ways to create different fuel cycle scenarios. The set of mass flow and economic
assessment modules must be divided into the following types:
• Front-end
• Reactor
• SNF storage
• Recycling (separation, fabrication of recycled fuel, etc.)
• Back-end modules
• Transportation

-6-
 Figure 1. AFC Classes of Modules

Front-end Modules
The functionality of the front-end modules must include, but is not necessarily limited to,
the modules sketched in Figure 2. The associated functionality does not necessarily have
to be ultimately organized in this fashion (modules A, B, C1/C2, D1).

Figure 2. Front-end Module Functionality

The front-end fuel cycle modules are generally related to commodity types of services
provided by commercial sources, hence “unlimited capacity” throughput.

-7-
 Module Module Name Allow General Description (NOTE, in VISION, these modules
limited have both non-economic and economic versions, thus
capacity? the descriptions are broader than only “cost”)
A Natural Uranium No Includes the factors involving extraction of uranium
Mining and Milling from the earth through production of uranium
concentrate in the form of U3O8 commonly known as
“yellowcake.” Module A needs to start with an initial
stock of conventional-pessimistic resources,
conventional-optimistic resources, or unconventional
resources. The values are user defined, the default
values shall be large (approximately infinity) so that
generally the model is unconstrained when it runs.
B Conversion No Takes the mined U3O8 concentrate and further purifies
and converted to a UF6 solid in cylinders for feed to a
uranium enrichment plant.
C1 Enrichment No Uses the UF6 solid in cylinders to enrich the % of U-
(Isotopic 235 from 0.711% to the 3–5% typical of the enrichment
Separation) used for LWR fuel fabrication, or higher for typical
VHTR fuels. Module C1 can supply LEU to either
unirradiated fuel (module D1) or recycled fuel (module
D2).
C2 HEU Blend-down No U.S. and Russian government-owned highly enriched
uranium (HEU) blended down as a secondary supply to
meet demand for low enriched uranium (LEU).
Module C2 can supply LEU to either unirradiated fuel
(module D1) or recycled fuel (module D2). Module C2
needs to start with an initial stock (outside AFCI, user
defined, default=0) of existing HEU potentially
available for blend-down.
D1 (and 8 Fuel Fabrication – Yes Uses chemical, ceramic/metallurgical, and mechanical
submodules) Unirradiated steps to take enriched UF6 and convert it to finished
(contact handled) fuel assemblies.

Reactor Modules
The functionality of the reactor modules must include, but is not necessarily limited to,
the modules sketched in Figure 3. The associated functionality does not necessarily have
to be ultimately organized in this fashion (modules R1, R2), but must be able to
differentiate between thermal and fast reactors.

-8-
 Figure 3. Reactor Modules

Reactors are integral to the fuel cycle. Reactor/transmutation baseline cost data are
provided in Appendix C of the 2005 Advanced Fuel Cycle Cost Basis. The SNF storage
(Module E) and SNF packaging for transport and disposal (module H) are generally
located at reactor sites.

The reactor modules are always handled in the “limited capacity” fashion.

Module Module Name Allow General Description (NOTE, in VISION, these

limited modules have both non-economic and economic
capacity? versions, thus the descriptions are broader than only
“cost”)
R Reactor Always Baseline data for future thermal and fast
(Thermal/Fast) reactors are based on Generation IV Roadmap
activity.

SNF Interim Storage Modules

When discharged from reactors, all fuels generate so much heat that they must be actively
cooled, hence “wet” interim storage. As fuels cool, they can be transferred to either
passively cooled (“dry”) storage or packaged for shipment elsewhere (Figure 4). (The
packaging module is covered elsewhere.) It is to be understood that “wet” does not
necessarily mean water. For example, sodium-reactor metal fuel is actively cooled by
placement in sodium, not water.

-9-
 Figure 4. Spent Nuclear Fuel Interim Storage Modules

Module Module Name Allow General Description

limited
capacity?
E1 Interim SNF Eventually Pool storage (at reactor) of SNF from existing commercial
storage – reactor reactor operations. When fuel is sufficiently aged that
wet active cooling is no longer required, it can be transferred
to dry storage (module E2) or SNF packaging (module
G2) for shipment elsewhere.
E2 Interim SNF Eventually Dry storage (at reactor) of SNF coming from reactor wet
storage – reactor storage and includes handling costs involved with transfer
dry from wet to dry storage. When it is moved, it goes to SNF
packaging (module G2) for shipment elsewhere.

Recycling Modules
The functionality of the recycling modules must include, but is not necessarily limited to,
the modules sketched in Figure 5. The associated functionality does not necessarily have
to be ultimately organized in this fashion (modules G2, F1/F2, E3, D2), but must be able
to differentiate between aqueous and pyrolytic separation. The recycle-fuel module (D2)
must be able to accommodate many types of input (enriched uranium, DU, BU, NpPu,
Am, Cm) and produce multiple types of recycle fuel. Unless the separation plant is co-
located with reactors, SNF must be packaged (module G2) before it can be shipped to
separation (or disposal).

- 10 -
 Figure 5. Recycle Modules

The recycle modules (D2, E3, F1 & F2, and G) are associated with reprocessing of the
fuel and may be provided by some combination of government and private sources.

Module Module Name Allow General Description (NOTE, in VISION, these modules
limited have both non-economic and economic versions, thus
capacity? the descriptions are broader than only “cost”)
D2 Fuel Fabrication – Yes Uses chemical, ceramic/metallurgical, and mechanical
recycled steps to take fissile material from the back-end fuel
cycle to convert to finished fuel assemblies. In some
cases, all stages of fabrication require remote
fabrication, e.g., MOX-NpPuAm. In other cases, all
stages require glovebox but not full remote handling,
e.g., single-pass MOX-NpPu. In other cases, some
steps are contact, some are glovebox, and some are
fully remote, e.g., assemblies that blend UOX, IMF-
NpPu, and Am targets.

- 11 -
 Module Module Name Allow General Description (NOTE, in VISION, these modules
limited have both non-economic and economic versions, thus
capacity? the descriptions are broader than only “cost”)
E3 Recycled products Eventually Storage of the actinide by-products produced from the
storage reprocessing of thermal reactor and fast reactor fuels.
Would typically be required to support blending needs.
Module E3 should start with an initial stock (outside
AFCI, user defined, default=0) of potentially available
weapons-grade Pu that could be added to the fuel cycle
system. Blending WG-Pu into new fuel would be
accounted for in module D2.
F1 Separation Yes Separation of SNF elemental components using
aqueous process to support recycling of fissile
– Aqueous
materials. Includes receipt of SNF through end-product
(Elemental
production.
Separation)
F2 Separation Yes Separation of SNF elemental components using a
pyrolytic process to support recycling of fissile
– Pyrolytic
materials. Includes receipt of SNF through end-product
(Elemental production.
Separation)
G1 HLW Eventually Conditions the waste, provides interim storage of the
Conditioning, treated waste, and packages the HLW in preparation for
Storage, and transport to a repository. Module G1 is downstream of
Packaging separation and fuel fabrication.
G2 SNF Conditioning, Eventually Same as G2, but for unprocessed SNF instead of HLW.
Storage, and Module G2 is downstream of wet storage (module E2)
Packaging and dry storage (module E1).

Back-end Modules
Some of the back-end fuel cycle modules (I, L and M) are the responsibility of the
government as provided by the Nuclear Waste Policy (NWPA)1. Only a limited number
of these types of facilities would be built (Figure 6).

1
Information on the NWPA can be found at http://www.ocrwm.doe.gov/ymp/about/nwpa.shtml.

- 12 -
 Figure 6. Back-end Modules

Module Module Name Allow General Description

limited
capacity?
G1 HLW Eventually Conditions the waste, provides interim storage of the
Conditioning, treated waste, and packages the HLW in preparation for
Storage, and transport to a repository. Module G1 is downstream of
Packaging separation and fuel fabrication.
G3 LLW Conditioning, Eventually Mass flow e.g. for LWR with Zr clad fuels are to be
Storage, and disposed as LLW instead of GTCC or HLW.
Packaging

- 13 -
 Module Module Name Allow General Description
limited
capacity?
G4 GTCC Eventually This is analogous to G1, G2, and G3 but for waste that
Conditioning, is GTCC at time of separation, e.g, Cs and Sr. Cs and
Storage, and Sr must either (a) be stored ~300 years to qualify for
Packaging near-surface disposal (module J) or (b) be disposed as
GTCC. Under current NRC rules, the only disposition
path for GTCC is geologic repository (module L)
I Long-Term Yes Long-term storage of SNF/HLW until shipped to a
Monitored geologic repository.
Retrievable Storage
J Near Surface Eventually Engineered or trench disposal of LLW including waste
Disposal (LLW) and fill placement, and monitoring.
K1 Uranium Low Conversion, storage, and disposal of depleted UF6. In
Conversion, priority some scenarios, this material is later withdrawn to use
Storage, and in breeder fast reactors.
Disposition -
Depleted
K2 Uranium Low Conversion, storage, and disposal of burned uranium.
Condition, Storage, priority In some scenarios, this is only a brief holding pad for
and Disposition - BU from separation (module F) to fuel fabrication
Burned (module D2). In other scenarios, this can be
“permanent” disposal (as can be DU in module K1)
with withdrawal decades later, if at all. Because of the
high cost of TRU storage in module E3, we do not store
burned uranium there; hence the need for a new BU
module.
L Geologic Yes Includes inception through closure for repository
Repository operations. VISION will keep the following streams
separate – SNF (which may be withdrawn later), HLW,
and GTCC.
M Other Disposal Yes Speculative SNF/HLW disposal alternatives to a deep
Concepts geologic repository, such as deep bore hole, and others.

Transportation Modules
The functionality of the transportation modules must include, but is not necessarily
limited to, the modules sketched in Figure 7. The associated functionality does not
necessarily have to be ultimately organized in this fashion (modules O and P), but must
be able to differentiate between low-level and high-level radioactive materials.

Figure 7. Transportation Modules

- 14 -
The transportation modules (O and P) support the transport of new fuel, recycled fuel,
and shipment of SNF, HLW and low-level waste (LLW). Transportation of raw fuel to
the reactor is provided by the reactor owner/utility. SNF transportation from the reactor
to interim storage and the repository is the responsibility of the government. High-level
waste and LLW transportation resulting from recycling could be provided by some
combination of government and private sources.

Module Module Name Allow General Description

limited
capacity?
O Transportation for Not Transportation of recycled irradiated fuel and SNF/HLW
High-Level applicable per relative unit, includes handling not already included in
Radioactive interim storage. Includes required operations to condition
Materials and package the SNF for shipment to the repository,
interim storage, or to a reprocessing facility. NOTE: the
non-economic version of this module, without economics,
will assemble an estimate of all flows of classes of
materials, e.g., GTCC, HLW, SNF, recycled fuel.
P Transportation for Not Transportation for new fuel, unirradiated materials, and
Low-Level applicable LLW per relative unit, includes handling not already
Radioactive included in interim storage. NOTE: the non-economic
Materials version of this module will assemble an estimate of all
flows of classes of materials, e.g., unirradiated fuels, BU,
DU, EU, and LLW.

Assumptions
The following assumptions are made regarding the development and use of VISION:
• Existing models that satisfy all or part of the expectations and requirements
described in this document will be located and be used if possible.
• Some new development or modification of existing models will be needed to
satisfy all the requirements.
• The model needs to be developed or modified in time to help provide cost
comparisons for decisions anticipated in 2007.
• The model will be distributed and used beyond the INL.
• The model will be of sufficient quality to pass independent external (external to
the INL) review for compliance with requirements and for technical soundness.

Requirements
The following section describes the team’s/customer’s requirements for VISION. These
requirements are divided into six major subject areas. Priority for each requirement is
indicated by a 1, 2, or 3 designations.

- 15 -
Flow Model Variables

No. Name Description: Priority Acceptance Criteria:

Track the total mass (Kilogram, Kg) flows and inventories of Fresh Verify output against base cases run from DYMOND-US. 10-09-05
Track Mass
1.1 Fuel, SNF, Recycled material, HLW, TRU through each phase of the 1 Ver1. Verify SNF Produced, Total Recycled Material and HLW
Inventories
nuclear fuel cycle (fuel development, reactors, recycling, storage). Produced. (All Modules)
Track the total mass (Kilogram, Kg) and process losses of the isotopes Verify output against base cases run from DYMOND-US. 10-09-05
Track Isotopes
1.2 of interest through each phase of the nuclear fuel cycle (fuel 1 Ver1. Verify SNF Produced, Total Recycled Material and HLW
Mass Inventories
development, reactors, recycling, storage). Produced.
For each Fuel Recipe fed into a reactor estimate the mass of SNF
Verify output of several selected fuel recipes against Argonne
1.3 SNF composition (Kilograms, Kg) that exits the reactor at the end of its reactor fuel 1
spreadsheet estimates.
cycle. This should be done for each isotope of interest in the fuel.
For each scenario, estimate the mass (Kilogram, Kg) of U, U233 and
1.4 U Needed 1 Verify base cases against spreadsheet calculations.
U235 and U233 needed for the fuel supply used in the reactors.
Verify(1) that the model is correctly estimating the quantity of
available material for each time period. The available material
Material Estimate material availability, timing and volume, of recycle
1.52 1 includes fuel components such as Np, Am and Cs. User selectable
Availability materials.
table(s)/chart(s) that track estimated raw material available.
(Modules affected: A, B, C, D1, K)

Track the kg-miles transported per year between scenario locations

(see requirement 4.13) for:
Verify(1) that the model is correctly estimating transportation
1. Uranium concentrates,
Transportation volume at each time period for each of the identified submodels.
1.6 2. Fabricated fuel, 2
Volume The model interface will supply a user selectable table(s)/chart(s)
3. SNF,
that tracks transported material.
4. Recycled fuel,
5. Waste

2
Requirements shown with strikethrough text were included in Rev. 0 of this document, but have been dropped as a requirement in this revision.

- 16 -
No. Name Description: Priority Acceptance Criteria:

Estimate the number of shipments, based on the transportation type(s)

selected to a repository for:
Number Of
1.7 1. SNF, 2 Verify against spreadsheet calculations based on use cases.
Shipments
2. HLW
3. Recycled fuel
Energy Efficiency
1.8 Calculate changes in energy efficiency factor. 1 Verify against spreadsheet calculations based on use cases.
Factor
Radiotoxicity Calculate the long-term heat generation in a repository (LTH), long-
1.9 Indices Of term groundwater hypothetical dose from the repository (LTD), long- 1 Verify against spreadsheet calculations based on use cases.
SNF/HLW term radiotoxicity (LTR), weapons-usable inventory (WU)

Estimate mass (Kilogram, Kg) lost through radioactive decay for each
isotope of interest for any stocks with a holding time greater than one -
year for each:
1.10 Radioactive Decay 2 Verify against spreadsheet calculations based on use cases.
1. Model module
2. Inventory at each generation of recycle
3. Location scenario selected by the user.
Estimate the heat load from material placed in the geological
Heat Load 1 Verify against spreadsheet calculations based on use cases.
1.11 repository.

- 17 -
Economic Analysis Functionality

No. Name Description: Priority Acceptance Criteria:

Estimate cost for recycle facility ownership options including:

Facility Ownership
2.1 1. government, 2. private, 3. hybrid (government and private). 2 Verify against spreadsheet calculations based on use cases.
Cost
Recognize that different facilities have different "owner" ship.

Incorporate cost module variables that are consistent with the AFCI
Verify modules against current Functional & Operational
AFCI Cost Cost Basis report. Ability to use mass flows, volumes, waste form,
2.2 1 Requirements and interface relationships defined in AFCI Cost
Modules reactors data, and specified modeling inputs to calculate representative
Basis.
fuel cycle costs for each module.
Estimate total fuel cycle and system costs including the LUEC, that Verify against cost data from accepted reports or from EMWG
2.3 Total Costs 1
includes fuel cycle and reactors cost a per kWh basis. spreadsheet calculations. ($/kWh)
Estimate the separation cost as a function of different separation Verify against cost data from accepted reports or from spreadsheet
2.4 Separation Cost 3
product combinations. calculations.
Estimate recycle fuel fabrication cost ($/kg) as a function of key
Fuel Fabrication Verify against cost data from accepted reports or from spreadsheet
2.5 processing parameters that can drive costs (e.g., fuel type, gamma 3
Cost calculations.
field, neutron emission rate, heat rate and facility size).
Front-end Fuel Incorporate Uranium front-end supply/demand variables and
Compare results to separate spreadsheet or calculations performed
2.6 Cycle supply and relationships to enable pricing fuel costs based on selected market 3
through separate Uranium model.
demand conditions.
Back-end Fuel Incorporate variables and algorithms to mimic simplified functionality Compare modeling results for packaging, transportation, and
2.7 3
Cycle of the RW-Total System Model (TSM). disposal against RW- cases run with the TSM.
Facility Conversion Estimate the total cost ($) to change the capabilities of a facility, e.g.,
2.8 3 To be determined
Costs change UOX-capable reactor to a MOX and UOX capable reactor.
Manual Cost Allow the user to override module costs including setting reactor costs Verify that the interface allows the user to override preset module
2.9 2
Overrides to zero to obtain fuel cycle cost estimates only. cost algorithms.
Provide functionality to perform (DPL like) cost uncertainty analysis
Verify that model provides uncertainty analysis consistent with
2.10 Cost Uncertainty and provide Tornado and Rainbow diagrams of cost variables that 2
independent DPL calculations.
have significant impacts on the costs.

- 18 -
No. Name Description: Priority Acceptance Criteria:

Provide functionality to compare individual modules, total modules,

Case Cost
2.11 and LUEC costs between multiple cases and provide means to identify 1 Evaluate separate cases individually.
Comparability
differences in case assumptions.
Provide capability to perform the waste flow analysis independent
Fuel Cycle
2.12 from the economic analysis, with the ability to turn economic 1 Verify functionality to turn off the economics.
Economic Analysis
capability on/off without influencing the balance of the model.

- 19 -
Analysis of Estimates or Measures

No. Name Description: Priority Acceptance Criteria:

Confirm that the model interface includes the functionality to run

Display alternative strategy/scenario in a simple to compare format
Alternative comparative scenarios and has the ability to display charts and
3.1 such as chart and/or table with differences calculated for all model 1
Comparison tables that list the results to allow easy comparison of scenario
variables.
outcomes. (User interface)
Perform sensitivity analysis of outcome values based on selected/key Confirm that the model interface includes the functionality to run
3.2 Sensitivity 3
input parameters. Display the results in a chart and/or table. sensitivity analysis.
Optimize a Optimize selected output variables based on a set of selected input Confirm that the model interface includes the functionality to run
3.3 3
Scenario parameters that use a user supplied objective function(s). optimizations with user defined objective functions.
Estimate when reactors are constructed (fleet size) based on
Reactor fleet size determined dynamically based on above criteria.
Reactor unsatisfied electricity/H2/other demand, retirement age of existing
3.4 1 Verify output against base cases run from DYMOND-US. 10-09-05
Construction reactors, first available date for new design, and mix for U and TRU
Ver1.
management,
Estimate the reactor number and mix based on total unsatisfied
Reactor Number Verify reactor number and mix determined dynamically based on
3.5 electric and/or H2/other demand, retirement age of existing reactors, 1
And Mix electric demand against spreadsheet calculations.
first available date for new design, mix for U and TRU management,
Separation and Fuel Verify reprocessing capacity is determined dynamically based on
The model must be able to be run with either unlimited separation and
3.6 Fabrication 1 need, unit size and time to construct against spreadsheet
fuel fabrication capacity - or - with user-defined capacity increments.
Capacity calculations.
Data Confidence Verify modeling software has capability to calculate confidence
3.7 Provide confidence intervals for selected output variables. 2
Intervals intervals.
Reactor fleet size determined dynamically. Based on economics.
Reactor (such as mill/kW-hr if a function of burnup, amount to be sent to Reactor fleet size determined dynamically based on above criteria.
3.8 Construction based repository, CO2 credits, government economic factors, anywhere in 1 Verify output against base cases run from DYMOND-US. 10-09-05
on Burn up the system, etc.) consider both H2 and electricity OR - link with other Version 1.
models e.g. NERAC

Reactor number and mix determined dynamically based on electric

Reactor Number demand. Based on economics.. ((such as mill/kW-hr if a function of
Verify reactor number and mix determined dynamically based on
3.9 And Mix based on burnup, amount to be sent to repository, CO2 credits, government 1
electric demand against spreadsheet calculations.
Burn up economic factors, anywhere in the system, etc.) consider both H2 and
electricity OR - link with other models e.g. NERAC

- 20 -
No. Name Description: Priority Acceptance Criteria:

Dynamically
The model should dynamically create reprocessing capacity based on Verify reprocessing capacity is determined dynamically based on
Create
3.10 need, unit size, time to construct (forward projection) and allow user 2 need, unit size and time to construct against spreadsheet
Reprocessing
defined reprocessing capacity. calculations. Verify user defined reprocessing capacity is available.
Capacity

- 21 -
General Model Architecture Elements

No. Name Description: Priority Acceptance Criteria:

Graphical User Develop a Graphical User Interface (GUI) for selection of values of Confirm that the model has a user interface available that allows the
4.1 3
Interface input variables and user selected options. user to specify input parameters and run scenarios.
Confirm that initially that model interface input parameters are
4.2 Default Values Provide default values for all input variables. 1
initialized with default values.
Multi-dimensional Provide the capability to work with up to a six-dimensional array, with Verify that the interface has acceptable default values at startup
4.3 1
Arrays a minimum of three dimensions. time.
Model could be run:
(a) through GUI, Verify that the GUI has a selectable interface based on technical
4.4 Input interface 1
(b) input deck, expertise or password profile
(c) at the programming/modeling level

Allow user to select the level of warning for inappropriate input.

Model can be run with
(a) prevent inappropriate input values,
Select (b) allow but warn,
Verify that the model has selectable warning flags on input
4.5 Inappropriate Input (c) warning turned off. 2
parameters.
Warnings
If running in GUI mode, automatically prevent inappropriate input
values. If running in "input deck" or "programming/modeling" level,
then prevent, warn, no-warn are all options.

Allow the user to define the mix of reactors and adjust the mix
4.6 Reactor Mixes 1 Verify that the interface allows the user to specify the reactor mix.
through time.
Allow the user to input reactor cost or set the cost to zero for fuel cost
4.7 Reactor Cost 2 Verify that the interface allows the user to specify reactor cost
estimates only.
Fuel "Types" and Allow the user to define fuel "types" in terms of reactor type, Verify that the interface allows the user to specify fuel types in
4.8 1
burn-up achievable burn up, etc. terms of reactor type, achievable burn up.
Allow the user to select among discrete values associated with Confirm that the interface allows the user to select discrete burn up
4.9 Burn Up Rates 2
input/discharge data composition sets, each labeled as to its burn up. rates based on reactor/fuel types.

- 22 -
No. Name Description: Priority Acceptance Criteria:

Allow users to adjust input to reprocessing facility as function of fuel

age (minimum). Allow as strategies
Reprocessing (a) oldest fuel first. Verify that the interface allows the user to adjust reprocessing
4.10 1
Throughput throughput as a function of fuel age.
In either case, also allow user to determine/input minimum fuel age at
time of reprocessing. (default value is 5 years)

The
Allow the user to adjust the size/throughput rates of specific classes of Verify that the interface allows the user to adjust the
4.11 Size/Throughput 2
facilities (modules). size/throughput rates.
Rates

Allow three modes of model operation:

(a) User input controls discrete processing plant capacity growth +
discrete repository capacity growth. Then interim storage is the free
variable and both processing plant and repository unit sizes must be
Modes of Verify that the interface allows the user to run the model via the 3
4.12 input/default. 1
Operation modes of operation.
(b) User input controls discrete processing plant and interim storage
capacity limit. Then repository inventory is the free variable.
(c) User input controls interim storage and discrete repository. Then
processing plant required is the free variable.

Allow the user to select different location scenarios (e.g. on-site Verify that the interface that allows the user to select different
4.13 Location Scenarios 2
processing, regional, national, global, or fixed (e.g. 1500 miles)). location scenarios (national, regional or fixed).
Allow the user to select different modes of transportation for each
Modes Of Verify that the interface allows the user to select different
4.14 material stream and the volume per load for a specific transportation 2
Transportation transportation modes and volumes for material streams.
mode (i.e. road, rail).
Allow user to either:
(a) define growth rate, Verify that the interface allows the user to specify the energy
4.15 Energy Outlook (b) use default projection such as EIA, 1 demand from either a defined growth rate from a variety of internal
(c) input data from other models, and external sources (e.g. NEMS).
(d) dynamic link with other models
Timing And Allow the user to define certain timing and sequencing parameters, Verify that the interface allows the user to adjust the timing and
4.16 1
Sequencing such as, interim storage time, reprocessing time, etc. sequencing for system parameters.
Select Input Allow the user to select for different input materials streams (e.g. Verify that the interface that allows the user to specify different
4.17 1
Materials Streams fuel). input material streams.

- 23 -
No. Name Description: Priority Acceptance Criteria:

Select For Allow the user to select for different recycled product streams coming Verify that the interface allows the user to specify different recycled
4.18 1
Recycled Streams out of recycling (MOX/IMF/FR). product streams coming out of recycling.
Verify that the interface allows the user to input loading and fuel
Loading And Fuel Allow the user to input the loading and fuel management scheme (how
management schemes (how much of each fuel type to start up, how
4.19 Management much of each fuel type to start up, how much core/target/blanket 1
much core/target/blanket replaced each refueling, etc) for each
Scheme replaced each refueling, etc.) for each reactor type.
reactor type.
Verify that the interface allows the user to specify which escalation
Allow the user to input different escalation schemes (e.g. Use U.S.
4.20 Escalation Schemes 2 scheme to use (e.g. US Department of Labor statistics for escalation
Department of Labor statistics for escalation of operations costs.).
of operations costs).
Allow the user to input different interest rates (e.g. Use U.S.
Verify that the interface allows the user to specify which escalation
Department of Treasury statistics for interest rates). Selectable as
4.21 Interest Rate 2 scheme to use (e.g. US Department of Labor statistics for escalation
different for different capital projects (at the module level) in fuel
of operations costs).
cycle, esp. if owner varies.
Allow the user to define an objective function that will optimize a
Verify that the software allows the user to define and run an
4.22 Objective Function specific set of outcome parameters based on selected model 2
objective function for optimization.
parameters. (see optimization requirement 3.3).
Allow the user to save and retrieve input files to a file name and
Save and retrieve
4.23 location of their choice and to reuse the saved file for later runs. Or 1 Verify that the interface allows the user to save/retrieve input files.
Input Files
create input files from other sources outside of this model.
Have the ability to produce graphical output of all model variables, or
Verify that the interface has the functionality to produce
4.24 Graphical Output reports/variables from an available list (see requirement 4.25) as they 1
charts/tables of all model variables selected by the user.
change through time.
Allow the user to select the number and type of output display or Verify that the interface allows the user to specify the type of output
4.25 Select Outputs 1
charts from an available list. (charts/tables) for each system variable.
Flag Extreme Verify that extreme condition warning messages flag when the
4.26 Flag output variables that exceed reasonable conditions. 3
Conditions model has exceeded reasonable conditions.
Drill Down Provide high-level visual displays of the model output that users can Verify that the interface allows layered summary reports that allow
4.27 2
Capability “drill down” through to increasing levels of detail for causal tracing. progressively more detailed sub reports.
Provide the user the capability to adjust the time limits and time
Time Step Verify that the interface that allows the user to adjust time
4.28 increments so that users can step through time to interpret system 2
Capability parameters and step through time and view the selected outputs.
behavior.

- 24 -
No. Name Description: Priority Acceptance Criteria:

Allow the user to save output files to a file name and location of their Verify that the interface allows the user to select and store scenario
4.29 Save Output Files 2
choice. output data.

Internal
Provide model internal consistency checks to prevent running Verify that the model has built-in consistency checks to prevent
4.30 Consistency 2
simulation cases that are not physically realizable. unrealistic conditions.
Checks
Non-Linear
Provide for non-linear changes in cost variable such as materials Verify that the model has the functionality to use non-linear
4.31 Changes In Cost 2
supply. functions in cost variables.
Variable
Provide for ability to accommodate fuel blending requirements
Verify that the model has the functionality to blend fuel based on
4.32 Fuel Blending relative to supply and product constraint assumptions including related 3
supply and product constraints.
inventory requirements.
Interface with DPL Provide an output file at the end of a simulation from a user specified Verify that the model produces an output file and that the output file
4.33 1
software time step that can be used by a DPL software program. can be read by a DPL software package.
Model must be able to track up to 100 isotopes. In each case, the
chemical element and the atomic number (and meta-stable state if
Verify the model can handle multi-dimensional arrays with up to
4.34 Number of isotopes relevant) must be differentiated. The model must also incorporate the 1
100 elements in a dimension
half-life of each isotope to facilitate shifting between mass units and
activity units.
Provide the user the option to turn on/off the economics calculations Verify that the interface allows the user to turn the economic
4.35 On/Off 1
for a simulation. analysis on and off for a simulation.
Missing economic Alert users when economic or cost data is not available due to the Verify that the interface alerts the user when economic data is not
4.36 2
data alert simulation configuration specified by the user. available for a simulation configuration.
Provide high-level visual displays of the model structure (module
Model Verify that the model has the functionality to display various layers
4.37 links and flow sequences) that users can “drill down” through to 2
Configuration of detail or portions of the model.
increasing levels of detail.
Model must be able to handle, at minimum, the following isotopes: Verify that the model includes the following isotopes: U235, U238,
4.38 Minimum isotopes 1
U235, U238, Np237, Pu238, Pu239, Pu 240, Pu241, Am241. Np237, Pu238, Pu239, Pu 240, Pu241, Am241.

- 25 -
No. Name Description: Priority Acceptance Criteria:

Allow users to adjust input to reprocessing facility as function of fuel

age (minimum). Allow as strategies
Reprocessing (a) youngest fuel first. Verify that the interface allows the user to adjust reprocessing
4.39 2
Throughput throughput as a function of fuel age.
In either case, also allow user to determine/input minimum fuel age at
time of reprocessing. (default value is 5 years)

The following fuel types must be included in the model:

o UOX (33, 51, and 100 burnup)

o MOX-NpPu, one-pass
o MOX-NpPuAm, multi-pass
o MOX-NpPuAmCm
o IMF-NpAm, one-pass
4.40 Fuel Recipes o IMF-NpPuAm, multi-pass 1 Verify that the specified fuel types are included in the model.
o IMF-NpPu-Am targets, multi-pass
o UOX to Converter Fast Reactor
o MOX-NpAm, one-pass to Converter Fast Reactor
o IMF-NpAm, one-pass to Converter Fast Reactor
o UOX to Breeder Fast Reactor
o MOX-NpAm, one-pass to Breeder Fast Reactor
o IMF-NpAm, one-pass to Breeder Fast Reactor

The following reactor types must be included in the model:

o Thermal Reactor -light water
4.41 Reactor types 1 Verify that the specified reactor types are included in the model.
o Fast Reactor – converter and breeder
o Thermal Reactor – very high temperature
The following energy demand scenarios for the U.S. shall be included:
Defined Energy - 0% annual growth rate in nuclear energy demand Verify that the defined energy outlooks are available for the user to
4.42 1
Outlooks - 1.8% annual growth rate in nuclear energy demand select.
- 3.2% annual growth rate in nuclear energy demand

- 26 -
No. Name Description: Priority Acceptance Criteria:

Except for the reactor modules, all modules must be able to run with
"unlimited capacity" throughput, that is, subject only to the demand
from the number of reactors, all other parts of the system are Verify modules in model can be run in an unconstrained (subject
unconstrained. Sufficient uranium is mined, sufficient fuel is only to the demand from the number of reactors, i.e. sufficient
4.43 Unlimited Capacity 1
recycled, sufficient fuel is fabricated, etc. to keep the specified number uranium is mined, sufficient fuel is recycled, sufficient fuel is
of reactors operating. "Unlimited" flow can imply commodity fabricated, etc.) throughput mode.
costing, i.e., an implicit assumption that whatever is needed will be
able to be purchased.

Must also be possible to run many of the modules with “limited

capacity” throughput, that is, the throughput is controlled by the
existence (or lack thereof) of a discrete number of facilities providing
a given function. “Limited capacity” flow will generally imply
costing on the basis of discrete plants. Reactor modules are always
run in “limited capacity” mode. At minimum, fuel fabrication and
Verify modules in model can be run in a constrained (subject to
fuel separation must be able to be run in “limited capacity” mode;
defined capacity of discrete facilities such as reprocessing or
4.44 Limited Capacity others will be defined later. The limited capacity for a given module 1
mining) throughput mode. Verify the constraints can be user
can be specified in one of two ways – user or automated or a mixture
defined or set by model default settings.
thereof.
• User-defined limited capacity means the user must define the
number of plants with specified capacity, facility lifetime, and facility
capacity factor.
• Automated limited capacity means that the model will define the
relevant parameters.

- 27 -
Hardware/Software

No. Name Description: Priority Acceptance Criteria:

The model should run on a standalone desktop PC or laptop computer

Verify that the model runs on desktop systems/laptops using
5.1 Computer using current technology and running the MS Windows XP operating 1
Windows operating systems.
system.
The model should be developed using off-the shelf commercial Verify that the software used to build the model is commercially
5.2 Software 1
software. available.
The model should be in open source so that analysts, Systems
Verify that the model can be provided to other users in two modes:
Transparent Engineers and project modelers can modify the structure and
5.3 1 one where the model equations are accessible and a second where
Architecture calculations within the model. This feature is available for only
the model equations can be viewed but not edited.
members of the AFCI program.
5.4 Non-Proprietary The model should be non-proprietary. 1 Verify that the software has no proprietary requirements.

5.5 Distribution The model should be distributed at a minimal charge to users. 3 Verify that the software has a minimal or no charge for distribution.

Number of Verify the model has no limit on number of characters in equation

5.6 No limit on number of characters in equation editor. 1
characters editor.
Number of array Provide capability for up to 500,000 elements in an array with at least Verify the model has capability for up to 500,000 elements in an
5.7 1
elements 3 dimensions in an array. array with at least 4 dimensions in an array
Number of model
5.8 Able to accommodate up to 64,000 elements in the model. 1 Verify the model is based on a 64 bit or larger platform
elements
Provide a locked (executable only) version of the model for any Verify that a locked version of the model can be distributed and that
Locked version 1
5.9 individuals outside User Group 1. a user can not unlock the model or access the source code.
Configuration Develop and implement a Software Management Plan that includes a Prepare a Software Management Plan and a Configuration Control
Control configuration control process for official model releases.
1 Plan before modeling work begins.
5.10

- 28 -
Constraints

No. Name Description: Priority Acceptance Criteria:

The model's default and uncertainty ranges will be consistent with the
current assumptions and formulas (e.g., unit consistency, code of
Constraints from
accounts, U.S. Dollar as the monetary standard, base year for all Verify that defaults for inputs and uncertainty ranges are based on
6.1 Advanced Fuel 1
calculations, etc.) as defined in the current AFC Cost Basis. Model good assumptions, formulas and reference data.
Cycle Cost Basis
constraints will be updated as the Advanced Fuel Cycle Cost Basis is
updated.
Use selected cost data (e.g. the sunk, operations and buildup costs of
6.2 Cost Data 2 Confirm that the model has the capability to select RW’s Cost data.
repository) developed by RW.
Present output units consistent with the YMP economic analysis so the Confirm that the output units are consistent with YMP economic
6.3 YMP Consistency 2
numbers can be compared. analysis so that cross comparisons can be made easily.
Have a minimum time unit of one month and a maximum time unit of Confirm that the model runs with a time step of a minimum of one
6.4 Time Step 1
one year. month and a maximum of one year.
Confirm that the model interface has the functionality to allow the
6.5 Stochastic Provide for stochastic inputs for selected variables. 2
model to use stochastic inputs for selected variables.
All units report by the model at the end of a simulation will be in
6.6 Units 1 Verify the model will provide mass output in Kilograms (Kg).
Kilograms (Kg).

- 29 -
Software Quality
The model identified in this SRS has been evaluated in accordance with the Software
Management procedures of the INL (MCP-550). Based on that evaluation the VISION is
classified as a “Level D” or “Deferrable” software application. The application does not
meet the criteria specified for a higher classification level. Data in the deferrable class, if
lost, can affect individual performance, but would not affect INL mission success.
Applications in this class have no requirement to be back on-line within a specified
period of time.

Quality Documentation
Software classified at a level D requires a minimal Software Management Plan (SMP) be
completed. The following documents will be prepared for this model:
A. Software Management Plan (SMP), which will include:
• Software Quality Assurance Plan (SQAP)
• Software Configuration Management Plan (SCMP)
B. Software Requirements Specification (SRS)
C. Software Platform Evaluation
D. Planning and Design Basis (sometimes called a Design description for software or
DDS)
E. User documentation

Optional software application documentation that may include a requirements traceability

matrix (RTM).

Performance Testing
Performance testing will be in accordance with the software quality assurance plan and
the software test plan. Presentations and publications for external communication using
data or results from VISION will require peer review before submittal.

Verification and Validation

Verification and validation refers to the process of determining whether the requirements
for a system or component are complete and correct, the products of each development
phase fulfill the requirements or conditions imposed by the previous phase, and the final
system or component complies with specified requirements. Verification evaluates the
system or component to determine if it satisfies specified requirements. Validation
evaluates the system or component for proof of correctness.

Reference Documents
Shropshire, D.E., K.A. Williams, W.B. Boore, J.D. Smith, B.W. Dixon, M. Dunzik-
Gougar, R.D. Adams. 2005. 2005 Advanced Fuel Cycle Cost Basis. Idaho National
Engineering and Environmental Laboratory, Idaho Falls, Idaho 83415. INEEL/EXT-04-
02282 Draft Rev A.

- 30 -