Fire Program Analysis
FPA
Software
Architecture
Document
Conceptual and Technical
Architecture
September, 2010
Version: 3.1
REVISION HISTORY
Version Date Changes Authors
0.3 2/28/2006 First submitted rough draft – Conceptual Architecture S Carty
0.4 06/2006 Second Draft, incorporate Steering Committee “outcomes” S Carty
document of 4/4/06.
0.5 12/11/2006 Get rid of Hazard/Risk/Value; First rough draft of the S Carty
Interagency Science Team recommendation. Incomplete,
focused on FPU level, missing some concepts.
0.6 1/8/2007 Review and update in Boise. Apologies to TQ for color S Carty
coding.
1.0 1/17/2007 Incorporate Boise feedback from 1/10 review. This is the S Carty
accepted Conceptual Architecture.
2.0 9/12/2007 Significant changes to large fire. New technical S Carty
architecture details. This is the first draft to include the
technical architecture to realize the full “software
architecture document”. Reviewed In Boise 9/26-28.
2.1 10/11/2007 Updates from Boise, IBM. Unsettled items are flagged S Carty
with “TBD“.
3.0 6/22/2010 Updating throughout. 7 performance metrics. No BDN. S Carty
3.1 9/13/2010 FSim instead of FSPro. EROS instead of NITC. Diagrams SCarty
updated.
i
Table of Contents
REVISION HISTORY ................................................................................................................................................ I
TABLE OF CONTENTS ...........................................................................................................................................II
SOFTWARE ARCHITECTURE DOCUMENT ......................................................................................................1
1 INTRODUCTION ..............................................................................................................................................1
1.1 PURPOSE......................................................................................................................................................1
1.1.1 Changes from the Conceptual Architecture............................................................. 2
1.1.2 What this document is not ....................................................................................... 2
2 EXECUTIVE SUMMARY ................................................................................................................................3
2.1 BUSINESS PROCESS .....................................................................................................................................3
2.2 SCIENTIFIC MODELS ....................................................................................................................................4
2.3 ARCHITECTURAL LAYERS AND PATTERNS ..................................................................................................5
2.4 SYSTEM IMPLEMENTATION .........................................................................................................................6
3 REQUIREMENTS ..............................................................................................................................................8
3.1 SYSTEM CONTEXT .......................................................................................................................................8
3.1.1 Out of Scope..........................................................................................................10
3.2 SYSTEM VISION ......................................................................................................................................... 11
3.2.1 Use Cases .............................................................................................................14
3.2.2 Users .....................................................................................................................16
4 MODEL CONCEPTS ....................................................................................................................................... 18
4.1 FPU AND NATIONAL MODELS ................................................................................................................... 18
4.1.1 National .................................................................................................................18
4.1.2 FPU .......................................................................................................................18
4.2 FIRE SCENARIO ......................................................................................................................................... 19
4.3 INITIAL RESPONSE SIMULATION (IRS) ...................................................................................................... 19
4.4 LARGE FIRE SIMULATION .......................................................................................................................... 20
4.5 FUELS AND VEGETATION CHANGE MODELING ......................................................................................... 20
4.5.1 Fuels Maintenance ................................................................................................20
4.6 PREVENTION.............................................................................................................................................. 21
4.7 GOAL PROGRAMMING ANALYSIS .............................................................................................................. 21
4.8 PERFORMANCE METRICS (PMS) ................................................................................................................ 22
4.9 VALIDATION.............................................................................................................................................. 22
5 SOFTWARE ARCHITECTURE .................................................................................................................... 23
5.1 ARCHITECTURAL DECISIONS ..................................................................................................................... 23
5.2 ARCHITECTURAL GOALS AND CONSTRAINTS ............................................................................................ 23
5.3 LOGICAL VIEWS ........................................................................................................................................ 24
5.3.1 Architectural Layers ...............................................................................................24
5.3.2 Structural Component Views..................................................................................26
5.3.3 Collaboration Views ...............................................................................................37
5.3.4 Design Model Views ..............................................................................................39
ii
5.4 DEPLOYMENT VIEWS & TECHNOLOGY PLAN ............................................................................................ 39
5.4.1 Network .................................................................................................................40
5.4.2 Software ................................................................................................................41
5.4.3 Hardware ...............................................................................................................42
5.4.4 Deployment Details ................................................................................................44
5.5 DATA VIEWS ............................................................................................................................................. 47
6 SUMMARY ....................................................................................................................................................... 47
7 APPENDIX ........................................................................................................................................................ 47
7.1 REFERENCES ............................................................................................................................................. 47
7.2 ARCHITECTURAL DECISIONS ..................................................................................................................... 47
iii
Software Architecture Document
1 INTRODUCTION
FPA PM (phase 1) defined an effective initial response organization, considering budgets,
resources, fires, and management objectives. FPA (phase 2) extends the scope to include fuels,
large fire, and other fire program components.
The FPA development “Inception Phase” completed with stakeholder agreement on the vision
on December 18, 2006. The Elaboration Phase started with a high-level Conceptual
Architecture, an earlier version of this document. During Elaboration, the Conceptual
Architecture has been refined into this, the Technical Architecture (TA), also known as the
Software Architecture Document.
1.1 Purpose
The Software Architecture Document provides a comprehensive architectural overview of the
FPA system. It presents a number of different architectural views to depict different aspects of
the system. It captures and conveys the significant architectural decisions on the system. The
FPA project is using “agile” development methods, which proscribe doing too much detailed
modeling before development. However, even agile development requires an initial architecture.
This document summarizes the current state of this initial architecture.
The Software Architecture Document presents the functional and structural “vision” for the
system. It describes the IT and business concepts that will collaborate within the system to meet
the requirements. Model views will represent:
System Context & Vision: The system context shows FPA’s role, boundaries, and
external dependencies at the enterprise level. The system vision shows the high-level
process flows within the system.
Models: The scientific models supporting the business needs.
Architecture: The underlying technology, data, and processing concepts that support
the model and system vision.
This represents the WHAT of a system – what does it do, what are the processes, what are the
entities, what are the components? This is known as the “problem space”.
The Software Architecture Document also defines the “solution space”, that is, how we are to
develop the system. This document address implementation patterns, mechanisms, physical
deployment, Web vs. PC-based, administration, browsers, databases, protocols, and other
solution specifics like those found in the Federal Enterprise Architecture documents.
The Software Architecture Document uses multiple model views of architecture:
View Audience Area Artifacts
Use Case All stakeholders Describes the set of scenarios and/or use Business use case
cases that represent some significant, central (BUC)
functionality of the system.
Logical Designers The design's object model based on the Analysis model,
requirements (BUCs and user stories). Also component and
describes important use-case realizations. activity diagrams
Data Data and fire Persistence: describes the architecturally Business domain &
domain significant persistent elements in the data analysis model
specialists model
Deployment Deployment Topology: describes the mapping of the Deployment model
managers software onto the hardware and shows the
1 of 50
system's distributed aspects.
Table 1 Architectural views
1.1.1 Changes from the Conceptual Architecture
This document details selected design and process views. The technical architecture answers
how we build the system. It identifies specific solution technologies and products. This
document, the full Software Architecture Document, moves this conceptual vision from IT
concepts to actual solution components.
1.1.2 What this document is not
This is not an exhaustive listing of system artifacts. The current requirements, models, and other
development artifacts are kept in development tools and repositories. These artifacts are often
databases and linked models, which can be difficult to represent comprehensively in a linear
and static format such as this document. The Software Architecture Document presents
selected views of these multi-dimensional artifacts to communicate a concise and coherent
picture of the system.
2 of 50
2 EXECUTIVE SUMMARY
FPA has three top-level goals:
Support fire planning
o To inform FPU management priorities and planning decisions.
Determine cost effective fire program. Effectiveness measures include seven modeled
performance measures, known as the Performance Metrics (PMs):
o Cost of large fires
o Probability of fire in the WUI
o Acres treated
o Probability of fire in highly valued resources (HVR)
o Initial attack success
o Acres burned below damaging threshold
o Acres burned above damaging threshold
Support budget request
o Results of the analysis support the request process
o To support the national budget allocation process
2.1 Business Process
The FPA Interagency Science Team (IST) defined an approach to address these goals. The
FPA architecture is based on the IST recommendation. The IST identified FPA’s business need
as a classic “decision support system” (DSS), relying on data from scientific models. The DSS
process steps follow:
1. Assess situation. Gather historic and current landscape and fire data.
2. Define objectives. Define the desired outcomes. Identify areas, attributes, and target
measures that relate to the PMs.
3. Define alternatives. Define management options which may achieve the objectives.
Users specify fire program activities and strategies - different mixes of fuel treatments
and initial response organizations - to be evaluated.
4. Assess impacts of alternatives. Model the expected outcomes of the alternatives.
Alternatives get evaluated in simulations. Impacts are measured PMs.
5. Analyze tradeoffs. Report on each alternative’s expected outcomes relative to
objectives. Synthesize and visualize the outcome differences between alternatives.
6. Make decision. Select an alternative to implement.
7. Implement decision. Execute the decision.
8. Monitor results. Measure and assess the decision’s outcomes. Monitoring is outside of
FPA’s scope. It is included here only to round-out the complete DSS process.
This process addresses FPA’s three top-level goals. Steps 1-3 support planning; 4-5 determine
effectiveness of fire program alternatives; 6-8 support the request, allocation, and other fire
program activities.
This process will occur at two fire program levels:
1. A detailed FPU analysis will support FPU planning and feed the national budget request.
2. A national analysis of the FPU alternatives will support national budget request
decisions.
Both levels use a modular set of component models and analytical tools. Detailed simulation
models play a significant role in the FPU analysis, whereas the national analysis incorporates a
simpler goal programming model that is informed by FPU simulation results. The national
analysis assists decision makers in:
Understanding the tradeoffs between fuel treatment investments, initial response
investments, prevention, and large fire suppression costs.
3 of 50
Making decisions involving expenditures considering fire program components, regional
differences, and goals of the land management agencies
The relationship between these two levels of analysis is illustrated in the following activity
diagram, which has been color coded to reflect the decision support steps listed above.
Figure 1 Decision support process and the interaction of the FPU and national levels
The business flow begins with a situation assessment – data collection and entry. The national
and FPU levels also jointly identify objectives, often related to the “wildland-urban interface
(WUI) and “highly valued resources” (HVR). The alternatives incorporate the national direction
as well as local objectives and constraints. The alternatives span a range of reasonable options.
The impacts of FPU alternatives are assessed via detailed scientific models. Alternatives could
be screened by FPU planners, resulting in a subset of alternatives passed to the regional/state
interagency managers for review before being sent to the national planning team along with
supporting data and synthesized analytical results necessary to support the national analysis.
At the national level, decision support tools are used to search among possible combinations of
FPU alternatives to provide a favorable balance of cost, performance, and risk as defined by
national priorities. This analysis informs strategic decisions by agency executives that ultimately
result in FPU-specific funding allocations by fire program component and agency.
Prior to distributing allocations to field units, additional simulations and tradeoff analyses at the
FPU may be used to inform decisions about allocation of fire resources across the FPU within
the budget approved by Congress for that budget year.
2.2 Scientific Models
The decision support process represents the business process “layer” of FPA. The “assess
impacts” and “tradeoff analysis” steps rely on the scientific models in the “business services”
4 of 50
layer. FPA “layers” are discussed below. Several simulation models interact to represent the
integrated impacts of the fire program components, as illustrated in the following diagram of the
FPU-level models.
Figure 2 FPU-level scientific models
Historic and current conditions data is combined to evaluate prevention, fuels, and initial
response management alternatives. The system generates a stochastic fire event scenario to
represent the variability inherent in fire seasons. Prevention modifies the human caused
ignitions. Fuels activities modify the fire behavior and fire resource productivity. The Initial
Response Simulator (IRS) uses this fire scenario to model the user-defined appropriate
management response (AMR) and resulting effectiveness of fire resources. The initial response
results are combined with fuels and other data to calculate large fire probability via behavioral
and statistical large fire simulations. Initial attack success, fire probability, and planned fuels
treatments are key data elements used to calculate the PMs. The system processes the many
stochastic results to describe the statistical distribution of PMs.
The national model processes the constituent FPU results (performance measures and cost)
and assesses the aggregate national impacts of funding and management decisions. The
national model focuses on multi-attribute tradeoff analysis. A goal program evaluates the
nationwide FPU scientific results to explore tradeoffs among the measures and the FPUs,
supporting national budgetary decisions.
2.3 Architectural Layers and Patterns
The system architecture implementing these processes and models uses layers and
components to separate business, technical, and scientific concerns. This layering is based on
an industry standard Service Oriented Architecture (SOA) solution stack. Although the FPA
design is not specifically targeting an “Enterprise Service Bus” type SOA, it uses SOA design
5 of 50
and architecture principles. This approach is flexible, modular, and responsive in a stand-alone
application, and positions FPA to integrate with other enterprise services.
Figure 3 Architectural layers
In the above diagram, the “Business Process” layer implements the FPA decision support
business process. The business process invokes a set of scientific models and other fire-related
services (through the “Services” layer to the “Business Service Component” layer) to derive the
PMs (impacts). The adapter layer between the business process and service layers allows each
service to be modified to support unique needs of each business process, without rewriting the
service’s code. The “Data Integration” layer represents the business domain model of FPA data,
such as fuels, management units, fire resources, historic, reference, objectives, alternatives,
and simulation outputs like IA success and fire probability. The top layer, “Consumer”, is
separated for flexibility in presenting business, scientific, and data aspects to the user. The
“Operational Systems” layer represents underlying IT services infrastructure.
The architecture also relies on a component-based design and patterns to address system
goals. Components help separate logically distinct models and processing, supporting a more
responsive development effort and a robust system. For example, each of the scientific models
can be developed as a functionally (semi)independent component. These and other business
services will follow the “service component” and “service integration” patterns to support a
migration path to improved (or alternate) scientific models as the system matures, while
avoiding wholesale re-engineering.
2.4 System Implementation
FPA serves a nationwide set of users, and must synthesize nationwide results. The deployed
system uses a “tiered” architecture. The tiers allow secure access for geographically distributed
users. The separation of the tiers also supports flexibility to scale and maintain processing and
storage needs. These needs are driven by fire simulations, statistical processing, analytical
services for the national goal program, and input from interagency regional and state managers.
6 of 50
Figure 4 FPA hardware deployment diagram
The system is deployed as an Internet-based application, hosted at the DoI EROS Data Center.
The location and hardware provide good reliability, interagency access, and proximity to other
key federal fire systems. The deployment environment is illustrated above.
The rest of this document describes in more detail the business requirements, scientific models,
and architecture supporting them.
7 of 50
3 REQUIREMENTS
The FPA vision, goals, and business use cases encompass fire planning and budgeting
activities both inside and outside of the FPA software system. This broader business process
includes decisions, approvals, documents, appropriations, and more that might not be controlled
by the FPA software. The system flow and system context diagrams in this section delineate
what the system does and does not do.
The requirements address the FPA business need:
FPU
Planning - Provide tools to support FPU level initial response, fuels, and prevention
planning.
Cost effective analysis - Assess the impacts of selected fire program components.
Budget request –Support national budget decisions with detailed FPU analyses.
Regional/State
Planning – Provide tools to support interagency regional/state managers to review
FPU alternatives.
Cost effective analysis – Assess the regional/state unit-level impacts of budget
alternatives.
Budget request – Support regional/state review by interagency managers with
scientifically valid analyses.
National
Planning - Provide tools to support budget decisions at the national level.
Cost effective analysis - Assess the national aggregate impacts of budget
decisions.
Budget request – Support budget request with scientifically valid analyses.
3.1 System Context
System context specifies a system’s place in the world. It identifies inputs, outputs, and
interactions with external “actors”. The system itself is represented by top-level use cases. In
requirements development, this is the first step in translating broad, business based scope and
goal statements into a “system”. This defines the “outcomes” we expect from the system.
8 of 50
Figure 5 FPA System context diagram – major concepts, not all inclusive
Note the symmetry of the business use cases with the decision support process introduced in
the executive summary. The content of some of the use cases will be described later, in 3.2.1
Use Cases. The inputs and outputs are summarized in the next two tables.
Table 2 Input data from outside the system
From Example Actors Inputs
9 of 50
From Example Actors Inputs
FPU FPU Planner Situation data (FMG, fire resources, …)
Local GIS shop Objectives (WUI, HVR)
State and Local planners FPU management alternatives
Regional/State Interagency managers Interagency budget guidelines
such as forest supervisors
and other line officers
who traditionally
participate in the budget
preparation process
National Data LANDFIRE Physical conditions (GIS coverages)
Sources USGS topography, boundaries, fire history,
WIMS weather, fuels, transportation, common
NIFMID attribute coverages such as WUI
National National Planner Interagency budget guidelines
WFLC National fire resources
Fire Directors Fire program budget appropriation
National Budget Leads NWCG standard production rates, other
Data Administrator lookup data
Table 3 Output data to outside the system
To Example Actors Outputs
FPU FPU Planner PMs, costs
FPA Information
Goal program analysis inputs, simulation results
GIS boundaries and other data
National National planner PMs, costs
Reports at interagency, department, agency,
program component, region/state/unit, FPU, and fire
resource category.
3.1.1 Out of Scope
Activities outside the scope of the system include:
GIS data creation and editing
o Exceptions – derived and intermediate model artifacts; the FWA QA/QC tool
o System defines standards that data must meet
The budget request itself. FPA will not create the budget request. FPA will not provide a
complete database of budget information.
National and Regional office budgets are out of scope
FPA will not track Facilities and Construction projects
Fuels plan details that go into budget request, like named projects
Severity funding
Cleaning of corporate data sources like fire occurrence and weather history.
Not intended to replace any department or individual agency financial systems
Will not provide an automated interface to any existing federal financial system.
Will not be designed as a non-federal budget tool.
10 of 50
3.2 System Vision
The system context indicates what is outside of the system. The system vision represents what
is inside. The top level business process is illustrated in Figure 1 Decision support process and
the interaction of the FPU and national levels in the executive summary. The two “swim lanes”
in that diagram – FPU and national – are further detailed below.
Figure 6 FPU level system flow represents the Interagency Science Team’s FPU level “wiring
diagram”, and is color-coded to line up with the DSS steps.
Figure 6 FPU level system flow
This diagram puts the DSS business process and the FPU-level scientific models in context. A
brief description an instance of this process follows:
1. Situation (green) - gather FPU information – FMG boundaries, fire resources, dispatch
locations, historic fire and weather.
2. Objectives (red) – Describe WUI and Highly Valued Resources
3. Alternatives (blue), include costs of each option:
a. Fuels – what and where (tabular). Includes planning year treatments and
anticipated future conditions.
b. Prevention – “level” of activity, similar to RAMS, but simpler.
11 of 50
c. Initial Response – resource combinations, dispatch logic to reflect AMR. The
management response will be passed from initial response to the large fire
model.
4. Impacts (yellow) - run simulation models. The system manages the following sequence:
a. The system batches combinations of options, ie 4 fuels options x 3 preparedness
options (initial response + prevention) = 12 fire program “alternatives”.
b. Each alternative is run for a stochastic fire scenario, perhaps 200 different
possible fire years, for 12 alts x 200 years = 2400 simulated fire seasons.
c. Run the models:
Create stochastic ignitions scenario
For each alternative
Modify ignitions based on prevention alternative
Modify fire behavior based on fuels alternative
For each fire year
Run IRS using preparedness option and fire scenario
Write results. If there are 400 fires in a year, x 2400 simulated seasons =
960,000 simulated fires (per FPU), 137 FPUs = 131,520,000 fires.
Run large fire burn probability using IRS escapes and fuels treatments
Once a year (or less if no significant condition or guidance changes)
Run large fire behavior model for five sets of input data
Run statistical regression on results, derive large fire equation
Generate many “large fire” samples using statistical model
For each alternative, derive burn probability from the sample.
d. System derives the expected values of the PMs for each alternative and the
many stochastic fires.
These model relationships are shown in Figure 2 FPU-level scientific models in the
executive summary.
5. Tradeoffs (purple) - Run reports and models to compare alternatives and assess
effectiveness.
6. Based on previous step, modify the alternatives, re-run simulations, view new
effectiveness.
7. Decision (cyan) - Submit the alternatives for regional/state review and national analysis.
After step 7, national planners run the national analysis (described below), which includes
regional review and national audit of the FPU analyses. Alter the national analysis, the FPU
planner knows the allocation and can re-run the analysis and reports for the fire program the
FPU will implement. See 5.3.2.1 Consumer Layer for a mapping between this process and the
system user interface.
The national process interacts with the FPU process as discussed earlier. The same basic DSS
process applies for the national analysis, as summarized in Figure 7 National level system flow.
12 of 50
Figure 7 National level system flow
The details of the DSS steps for the national process include:
1. Situation (green) – Define national resources (for FPU analysts use in FPU models).
Administrators prepare reference data.
2. Objectives (red) – Let FPUs know management emphasis for alternatives.
3. Alternatives (blue):
a. Regional and State planners review the submitted FPU alternatives
b. National Planners audit the alternatives submitted by the FPUs for adherence to
guidance - do they provide enough “decision space” for the national analysis?
c. Define alternatives to the goal program model
i. Set constraints, such as different FPU and national funding scenarios
ii. Set priorities, such as PM targets and weights.
4. Impacts (yellow):
a. Process the FPU results for subsequent goal programming analysis.
b. Combine FPU results with national alternatives in a national multi-attribute
tradeoff analysis, using goal programming.
5. Tradeoffs (purple) - Run reports and models to compare alternatives and assess
effectiveness.
6. Based on previous step, modify the alternatives, re-run models, view new effectiveness.
7. Decision (cyan) – National planner uses PMs, cost, organization, and perhaps other
data to identify funding levels for each fire program component at each FPU.
13 of 50
3.2.1 Use Cases
Business use cases encapsulate flows and provide a structure. The system requirements are
refined as “user stories” for system development. The system flow diagrams above translate
into a use case model, represented by the following overview diagrams. These diagrams are
simply another view of the flows described above.
Figure 8 Summary use case model of FPU level
This diagram identifies important activities and actors in the system. This overview only includes
significant actors and activities in the system, and is not intended to be a comprehensive listing.
The following table summarizes these and other significant FPU level business use cases.
Table 4 Descriptions of FPU business use cases
Decision support step Use case purpose
Assess Situation Manage various current and historic situational data; clearly represent
the "situation".
Define landscape
Define FPU fire resources
Define dispatch locations
Define current fuels
Define historic fires
Define historic weather
Define Objectives Manage various planning objectives. This describes the desired PMs
and locations.
Important Resources – “Highly Valued Resources” (HVR)
WUI
Define Alternatives Manage and select from a set of program component options; define
combinations of options – a complete set of options is an “alternative”;
define and visualize each alternative.
14 of 50
Decision support step Use case purpose
Define prevention option
Define initial response option
o Fire resources, dispatch locations, and dispatch logic
Define fuels option
Assess Impacts For each combination of fire program component options, the system
runs simulation models to assess impacts.
Generate stochastic fire scenario, modify ignitions by prevention
and behavior by fuels
Simulate initial response
Calculate large fire burn probability
Calculate PMs
Analyze Tradeoffs Use reports to compare alternatives and their impacts.
Visualize impacts within and between alternatives
Make Decision Before budget request
Screen alternatives for regional review and national analysis.
.After budget allocation
Select alternative to plan for budgeted year.
Implement Plan Run reports on the implemented alternative as needed to support initial
response, fuels, and prevention planning.
Figure 9 Summary UC model of national level
The figure above identifies significant national analysis use cases. The table below describes
these and other
15 of 50
Table 5 Descriptions of national use cases
Decision support step Use case purpose
Assess Situation Manage nationally provided situation data.
Define national fire resources
Define WUI locations
Define reference data
Define Objectives Provide objectives guidance to FPUs
Define Alternatives Manage and select from a set of national alternatives (combinations
of FPU alternatives); define and visualize each alternative.
Review of alternatives by region/state planners
Audit FPU alternatives
Define funding scenario, other constraints, and priorities
Assess Impacts Process all submitted FPU model inputs and outputs, run through the
goal program.
Analyze Tradeoffs Evaluate goal program outputs and other reports to understand
similarities and differences between alternatives and their impacts.
Create "new alternatives" based on tradeoff model results.
Make Decision Select a combination of FPU alternatives for budget request.
Implement Plan Identify allocated FPU program component funding levels.
3.2.2 Users
There are two primary customers of the FPA system:
National level, represented by WFLC and the agency fire directors. As users, WFLC will
generally view budget request reports.
FPU level, represented by the fire planners and line officers. At this level, the users will
be interested in the detailed outputs of the simulation models, and how they will be used
for local decisions and in the budgetary decisions.
The primary users of FPA are planners at the FPU and national levels. Their planning and
analysis activities provide the data underlying the budget request. Regional planners may
access reports and help audit that the FPUs have followed guidance. Other stakeholders will
(generally) interact with the FPA system through one of these types of users, as illustrated in the
context diagram and the following view of FPA stakeholders.
16 of 50
Figure 10 FPA actors and stakeholders
Figure 10 FPA actors and stakeholders is a UML diagram. The solid lines with closed arrow
heads represent “is a kind of” relationships. Note that the system itself is represented as an
“actor”. For clarity, such “system” actors are colored black, and human actors are gray.
FPA PM (phase one) developed the concept of an “FPU Team”. This is a multi-agency group of
local planners collaborating on a budget request. Phase two will continue the FPU Team
concept.
17 of 50
4 MODEL CONCEPTS
“All models are wrong. Some models are useful.” - George Box, statistician, 1979.
We model to simplify concepts and focus on meaningful elements of the fire business. Toward
that end, FPA will employ multiple models within the system:
Geospatial models to support fire planning. Users can describe management attributes
(inputs to the system) through models. Conditions on the ground may be derived from
models. Fuel treatment, fire resource, and other strategy effectiveness may be derived
from geospatial models.
Simulation models will calculate the impacts of user-selected management alternatives.
In general, discussions of “the FPA model” refer to the simulations.
Statistical models. Statistical analysis of historic and simulated data may itself result in
models such as regression analyses, which in turn can generate “simulated” data.
Goal programming models will provide insight in to the relationships among the
management alternatives and their impacts
The user’s experience of these models is defined by the system requirements. Some models
include direct interaction with model concepts and elements, others don’t.
This section briefly reviews FPA model concepts. For more details, see the Interagency Science
Team’s report.
4.1 FPU and National Models
FPA analysis will occur at two levels – FPU and national. Goals and objectives, constraints, and
the specific national budget alternatives being considered in a given budget year are passed
between the two levels as part of the annual budget formulation process. Following detailed
simulations and trade-off analyses at the FPU level based on an array of budget allocation
choices, FPU model results are synthesized in different forms and passed back to the national-
level analysis. “FPU model results” in this case represent a set of FPU alternatives, not a single
output. At the national level, decision support tools facilitate strategic choices across all FPUs.
National decisions result in FPU-specific allocations by fire program component and agency.
Finally, additional simulations and tradeoff analyses at the FPU level inform decisions about
allocation of fire resources across the FPU within the chosen budget level.
4.1.1 National
The national analysis applies decision support tools (e.g., goal programming trade-off analyses)
that are informed by FPU-level analyses. These tools include formal methods for searching
among alternatives, evaluating trade-offs and implications of various weighting or prioritization
of performance measures, and explicitly address risk and uncertainty. Detailed simulations of
the consequences of different fire program investments at the FPU level are synthesized and
used in national-level analytical tools. The decision support tools used at the national level
display the data and model results from FPU-level analyses to reveal the structure of the
decision space and the consequences of the alternative allocation strategies available to
national-level managers, as quantified by the PMs formulated at the national level.
4.1.2 FPU
FPU-level analysis applies detailed simulation and decision support. Simulation allows
consideration of complex processes that interact at the FPU level including weather,
topography, vegetation, and other factors that influence fire behavior. It also allows
consideration of impacts on spatially distributed resource values and other performance
measures. Based on national guidance, detailed simulations of the consequences of alternative
levels of investment in different fire program components are conducted at the FPU level.
Decision support tools display data and model results from FPU simulations in terms of
18 of 50
consequences of budget alternatives for the PMs and for the structure of the decision space
available to managers. Results are synthesized and passed back to the national level to inform
budget formulation decisions made there. The FPU analysis focuses on the consequences of
different FPU resource distribution strategies within the specific budget allocation to that FPU by
agency.
Figure 11 Summary of FPU level models
The above figure illustrates the interactions of the FPU models. The models are detailed below.
4.2 Fire Scenario
The natural variability of fire seasons will be accounted for using a stochastic fire scenario to
feed the initial response simulation. Historic weather and occurrence analysis will drive
generation of stochastic fire scenarios. Fire scenarios include ignitions and behavior, so the
scenario module will interact with prevention and fuels alternatives.
4.3 Initial Response Simulation (IRS)
Initial attack effectiveness will be derived using a stochastic simulation. CFES2 serves as the
conceptual basis for FPA’s approach. Users will define organizations and “dispatch logic”. Fire
resources will be applied to the fires according to the dispatch logic requirements. AMR such as
WFU or “less than full suppression” may be represented through the dispatch logic.
Initial attack success rate is the primary IRS output. Escaped fires, which exceed the
capabilities of the simulated initial attack organization (known as “exceed simulation limits”, or
ESL), have the greatest potential to influence final PM outcomes, e.g. damages and area
burned, derived in the large fire model. Obtaining accurate characterizations of ESLs is critical
for modeling the effects of budget trade-offs among initial attack, large fire, suppression,
prevention, and fuels management programs. This is the primary role of IRS.
19 of 50
4.4 Large Fire Simulation
Large fires, irrespective of their actual size, are those that are not suppressed in the IR
simulation. The large fire simulation estimates:
Probabilities of fire impact represented by burn probability and fire intensity
Size of fires
Costs of large fires using the “Stratified Cost Index” model.
The large fire model is really a series of models:
1. Calculate burn probability and intensity for a limited set of fires (locations and fuels).
FSim is the computationally-intensive behavior model used for this.
2. Derive a large fire size regression equation from the FSim outputs, and then use the
resulting equation to generate many more large fire “samples”.
FSim’s basic algorithm follows:
For fires randomly generated based on historic occurrence
o For each stochastic weather scenario (using processed historic weather)
Calculate the fire probability
Aggregate and normalize probabilities
Several components already exist and have been leveraged, either logically or physically.
FLAMMAP calculates the innermost fire probability for a given event and a given weather
stream. FSPro is a wrapper around FLAMMAP which iterates over multiple (stochastic) weather
streams. FSim is an outer wrapper that launches FSPro for multiple ignitions. IRS itself uses a
multi-year stochastic fire scenario.
FSim requires significant processing power. Coarsening the model resolution (from 30 meter to
270 meter cell size, for an 81x reduction) and running tests indicates that, with the proper
dedicated 64 bit, 16 processor hardware, a single run of an FPU-sized area can be processed in
between 2 hours and 3 weeks.
To address the processing demands, FSim is run five times for each FPU, varying significant
parameters such as weather and fuels. These runs provide raw data run a regression analysis,
resulting in a parameterized function which can quickly give many “pseudo-samples” of large
fires. The resulting data represents a robust distribution that allows consideration of an arbitrary
range of conditions, reflecting a range of fire management alternatives.
4.5 Fuels and Vegetation Change Modeling
FPA uses surface fuel models and canopy attributes to represent the vegetative condition. The
downstream models of fire behavior, suppression, and burn probability will reference the
changed fuels data, and intrinsically reflect the impacts of the treatments in the resulting PMs.
FPA will not model the temporal variability inherent in natural systems, as done in VDDT. In
FPA, the planner will simply describe the “future fuels condition” as if it were another treatment,
that is, the user will describe the future fuels assuming some treatment regime based on the
current fuels. To do this, users develop fuel treatment options by describing fuel treatment
effects in terms of the number of acres modified to meet the fuels objectives. The user specifies
existing fuel models and post-treatment fuel models with canopy attributes for all treatments
applied to the FPU. The fire event scenario, initial attack, and landscape fire simulation models
are run to calculate the new post-treatment impacts (PMs) for the planning period.
4.5.1 Fuels Maintenance
FPA will model the impact of an FPU's existing fuels condition and also the fuels condition
resulting from future fuels treatments. In order for fuels conditions to persist through time, FPUs
20 of 50
will need to perform annual fuels maintenance treatments. These maintenance treatments will
prevent an existing fuels condition from reverting to a pre-treated fuels condition.
4.6 Prevention
Conceptually, the prevention model relates prevention actions with changes in human caused
ignitions. FPA will use a simple variant of the concepts used in RAMS (Risk Assessment and
Mitigation Strategies). RAMS uses established factors for prevention effectiveness. The
following spreadsheet presents key concepts:
trtmt effectiveness Stat Causes Option
Treatments RR fires smoking child Lightning campfire arson
Current A B
Patrols 0.00 0.05 0.06 0.00 0.10 0.02 1 0 0.1
Inspection 0.01 0.00 0.00 0.00 0.15 0.01 1 0 2
Signing 0.00 0.03 0.01 0.00 0.04 0.01 1 0 2
RR Inspections 0.05 0.00 0.00 0.00 0.00 0.00 1 2 0.5
Community 0.01 0.05 0.10 0.00 0.03 0.10 1 0 0
Preventability 0.60 0.40 0.30 0.00 0.50 0.10 Tot Program Effort
5 2 4.6
factor # fires by cause 1.00 1.00 1.00 1.00 1.00 1.00 Total Ignitions
# ignitions 20 1 4 180 2 1 208
factor # fires by cause 0.70 2.00 2.00 1.00 2.00 2.00 A
# ignitions 14 2 8 180 4 2 210
factor # fires by cause 1.56 2.00 6.54 1.00 0.82 3.33 B
# ignitions 31.1111 2 26.15 180 1.641026 3.3333 244.2
Table 6 Prevention model concepts
In the table, the treatments (yellow boxes) are prevention program Education, Enforcement and
Engineering activities. Each activity has a different effectiveness on different fire stat causes
(blue). Each program “option” (grey headings) represents different levels of funding among
prevention activities. The resultant ignitions by stat cause are calculated based on the
established factors. Note the factors in the table are NOT the actual factors. They are for
illustration only.
4.7 Goal Programming Analysis
Goal programming employs optimization. Two approaches are pre-emptive and non-pre-
emptive.
Pre-emptive GP puts a priority ordering on each attribute, as well as a target value. It
then runs a series of optimizations on each attribute in priority order, setting the
“optimized” results as an attribute constraint in each subsequent run. This is a “priority”
based multi-attribute analysis.
Non-pre-emptive GP has a single objective - minimize deviation from a vector of
weighted attributes, for example the seven PMs. Users can weight the objectives
differently and assess the resulting solution. This is a “weight” based multi-attribute
analysis.
The national budget leads have identified a hybrid pre-emptive and non-pre-emptive model for
FPA to employ. Attributes (the PMs) will first be grouped into pre-emptive priority groups. The
model will try to meet the target values of attributes in group one first, then holding the values
attained as constraints, attempt to meet the targets for group two’s attributes, and so on. Within
each group, the attributes will be weighted to normalize the values, so they are conceptually
21 of 50
equivalent. By applying these “normalizing” weights within a priority group, each group becomes
a non-pre-emptive goal program.
In FPA, the objectives include the PMs. Decision variables include fire program component
funding levels. Constraints include various cost limits.
The system uses weights between PMs (in non-pre-emptive GP), but not within a PM. For the
performance measures, this means:
One acre of WUI at high risk of fire is always exactly equal to every other acre of WUI at
high risk of fire.
One area trending toward desired condition is no more important than any other area
trending toward desired condition.
A high IA success rate in one area is equal to a high IA success rate anywhere else.
Etc.
Note that goal programming is only intended for use in the national analysis.
4.8 Performance Metrics (PMs)
At a high level, the PMs are stated as program objectives. FPA uses the following model
outputs as proxies for those seven program objectives:
1. The probability of costly fires.
2. The probability of fires within the WUI.
3. The acres treated for fuels.
4. The probability of a fire within a highly valued resource area.
5. Initial attack (IA) success rate.
6. Acres burned below a damaging FIL
7. Acres burned above a damaging FIL
The PM estimates are the expected values (from many stochastic simulations), where
correlations between measures are taken into account.
4.9 Validation
FPA will not compare modeled PMs with “actual” PM performance in the field. Monitoring of fire
programs implemented and comparison to what had been planned is OUTSIDE the scope of
FPA.
See the Interagency Science Team’s report for details on validation of the scientific models.
22 of 50
5 Software Architecture
FPA’s software architecture is the foundation for implementing the processes and models of the
preceding sections. The rest of this document focuses on IT concepts and details supporting
those needs. The diagrams use the unified modeling language (UML), an open standard
notation. The architecture represented in these views addresses the requirements via:
Software layers: Limit dependencies in code and logically group responsibilities. This leads to
more robust and responsive system development. The primary layers in FPA were
presented in the executive summary and are discussed below.
Component-based development: Encapsulate functionality and allow developers to divide a
complex system into well defined pieces. Since components are somewhat self-
contained, they can be developed independently, allowing the development effort to
scale. Components support “pluggable” maintenance via well-defined interfaces, so a
system can evolve as new science and business needs arise. In the UML, components
can be identified with the “>” stereotype label, and/or by an “electrical
plug” icon (although they are often simply represented as rectangles to reduce clutter).
Design patterns: Use established approaches to commonly occurring needs. Patterns increase
development speed and quality by re-using proven solutions. The following sections
describe the patterns used as appropriate.
The following sections will present both structural and dynamic views. These details will include
entities, products, operational models, data structures, and non-functional requirements.
5.1 Architectural Decisions
Several solution decisions have been made either to support the requirements or as part of the
requirements. These decisions and associated rationales are detailed in the appendix, and
listed here:
1. Use geospatial technology.
2. Incorporate many specific technologies identified by the Interagency Science Team and
others.
3. Implement as an enterprise application.
4. Use service-oriented layers.
5. Implement business services as service components.
6. Create a rich client interface that meets FPA usability standards.
7. Create a component based UI software architecture
These and other decisions are discussed in the following sections.
5.2 Architectural Goals and Constraints
These are broadly stated guidelines informing the architecture. Most architectural goals, such as
performance and availability, are defined in the non-functional requirements (see references in
the appendix). The following goals supplement the non-functional requirements with
architectural constraints.
Modular design. The system in general, and the simulation models specifically, must be
modular, to replace and improve simulation models and business processes as the
system matures.
Usability.
o The system design should support flexible user experience alternatives by
separating the presentation, model, and logic architectural layers.
o Reduce workload on users by leveraging enterprise applications, services, and
data
23 of 50
Manageability. The system must be deployable and manageable across the five federal
wildland fire agencies, as well as state and local agencies.
Persistence. The system must support records retention guidelines for planning
documents.
Testability.
o Technical architecture - should support automated testing where possible.
o Business process - the outputs must be usable in the business process.
o Scientific - see section 4.9 Validation.
Flexibility. The system must support analyses on varying spatial extents and varying
administrative boundaries. The primary path is to support the five federal wildfire
agencies’ budget requests. However, state and local users may want to run analyses for
different spatial extents for different reasons.
5.3 Logical Views
5.3.1 Architectural Layers
The top level software architecture divides into the following “layered” packages:
Figure 12 Architectural layers in FPA
The top-to-bottom dependencies isolate responsibilities in the software, improving development
responsiveness to requirements and change, and maintainability. As the business process is
defined and refined, this separation will reduce impacts to other parts of the system. The
following table summarizes each layer’s responsibility.
Layer Purpose
Consumer Often the “presentation” layer - the user interface.
“Consumers” can also be other systems.
Business Process The business logic layer, which controls the lower level
functions to meet the business needs by choreographing
lower level business services.
Service This layer exposes and adapts general-purpose low-level
services (or functions) to support the specific needs of
specialized high-level processes.
Business Service Fire domain services that support the business needs.
24 of 50
Layer Purpose
Component Implementation details are hidden from the other layers.
This includes the scientific models (IRS, etc.).
Data Integration The business data, or “entities”, integrated to support the
Mediation layers above.
Operational System Common services and products for low level, non-
business-specific functionality, these may support any of
the higher level layers.
Table 7 Architectural layers and their roles
Note the color scheme of the above layering diagram. It will be used throughout sections 5.3.2
Structural Component Views and 5.3.3 Collaboration Views. This layering is a software
dependency structure, and does not imply a business process.
This layering is based on an industry-standard Service Oriented Architecture solution stack. The
logical layers defined in this stack provide a flexible and maintainable structure for component-
based development. The layers do not impose an SOA solution, but they do encourage good
services-based design. The symmetry between FPA layers and the SOA solution stack can be
seen in the following view of the stack, which illustrates several ways that higher order
processes can be built from more atomic services and components.
Web
Service Consumer
Consumers JSF Ajax Other
Svc
Quality of Service (Security, Management &
Data Architecture (meta-data & services) &
Monitoring Infrastructure Services)
Business Processes
composition,
Business Intelligence
choreography
Governance
Integration
Services
atomic and composite
Service Provider
Service Components
Operational Systems COTS Custom
Application
applications and data
Figure 13 SOA Solution Stack
The five horizontal “functional” layers serve the same basic role as the corresponding FPA-
specific layering described earlier (the FPA “Business Service Component” and “Data
Integration Mediation” layers are both “Service Components”). The cross-cutting vertical “non-
functional” slices on the right include:
Layer Purpose
Integration Provides the capability to mediate, route, and transport
service requests from the service requester to the correct
service provider.
Quality of Service Capabilities required to realize nonfunctional requirements
(NFRs).
25 of 50
Data Architecture Ensures the inclusion of key considerations pertaining to
data architecture and information architectures.
Governance Covers all aspects of business operational life-cycle
management.
Figure 14 Non-functional, cross-cutting layers
SOA represents one possible use of services. FPA will generally use service components within
the FPA application itself, rather than through heterogeneous integration using an SOA or
Enterprise Service Bus. Nonetheless, adopting these patterns and layers will position FPA to
both provide and consume services when enterprise wildland fire systems mature to that point.
5.3.2 Structural Component Views
The primary components and their containing layers are represented in Figure 15. The details of
these relationships are presented later, in the section on “collaboration views”. This diagram
only presents significant elements at a high level of abstraction, and excludes the “Operational
Systems” for conciseness.
Figure 15 Overview of important components, FPU level
This diagram shows the dependencies between the layered architecture. Note that the
directions of the dependencies obey the top-level layering indicated in Figure 12 Architectural
layers.
5.3.2.1 Consumer Layer
The user experience (UX) is a significant part of the Consumer layer, realized as a user
interface. This layer depends on the underlying business layers, and is customized for the
26 of 50
business processes underlying it. At the top level, there will be two interfaces – one FPU and
one national.
5.3.2.1.1 UI patterns
This layer includes the “view” of the model, view, controller (MVC) design pattern. An MVC-
based architecture allows different views of the application while reusing the same business
logic and underlying model. Separation of this layer will allow use of different UI technologies in
the technical architecture. These might include Rich Internet Applications, AJAX, HTML, and
others. For development and maintenance benefits and component richness, FPA uses the
Backbase commercial UI library.
A consumer “agent” pattern will isolate consumers from the need to know details of the services
that it consumes. The agent also manages dependencies between actions and the application
context. The following diagram illustrates key consumer layer elements.
Figure 16 Consumer layer design elements
Instances of the user interface will exist for corresponding business processes, as well as the
lower level simulation models.
5.3.2.1.2 User Experience
The diagram below illustrates the relationships between key elements of the user experience.
These elements are based on the UI prototype developed and usability-tested during the
elaboration phase. The “ApplicationInterface” with the > stereotype represents a
“boundary” between the user and other components of the system. This is generally a web
page.
27 of 50
Figure 17 User experience component model
Navigation in the user interface reflects the Decision Support Process described earlier, and is
mapped as follows:
Decision Support Step User Interface Navigation (FPU)
Assess Situation Input Data
Define Objectives
Define Alternatives Options
Alternatives
Assess Impacts Run Models
Tradeoff Analysis Reports
Decision Prepare and Submit
Implement
Monitor N/A
Table 8 Decision Support System-to-user navigation mapping, FPU
5.3.2.2 Business Process Layer
Business process layer components are structured according to the standard decision support
process described earlier. Key business layer components and their descriptions follow:
Table 9 FPU business process components
Component Purpose
Manage FPU DSS Process Coordinate and provide status on the decision support
process described in the requirements.
“Input Data” Manage various current and historic situational data. Some
Manage FPU Team and Analysis are provided by the system rather than the user:
Manage IR Inputs Define landscape
Manage Landscape Data Define FPU team & resources
Define dispatch locations
Define current fuels
Define historic fires
Define historic weather
Define HVR
Define WUI
“Options” Manage various fire management options, by program
Fire Program Alternatives component.
28 of 50
Component Purpose
FL Options Define fuels treatments
IR Options Define dispatch logic (appropriate management
PV Options response)
Select fire resources for each option
Define prevention levels
Run Models Combines program component options and executes
simulation models; post process results to calculate PMs.
Manage Reports Coordinates selection of alternatives and outcomes to
compare.
Technical Review Manages screening alternatives for submit to national and
Line Officer Review identification of alternative to use for implementation.
Submit to National
Note that the scientific models of “assess impacts” are in a layer below this business process.
The national level business process is based on the same decision support process, but the
components differ.
Table 10 National business process components
Component Purpose
Manage National DSS Process Coordinate and provide status on the decision support
process described in the requirements.
Input Data Manage various current and historic situational data
Define national reference data ie. WUI
Define national resources
Manage various national objectives and
communication of guidance to FPUs.
Audit FPU analyses
Options Manage various fire management alternatives.
Define funding scenarios
Manually select and constrain
Run Models Invokes processing of submitted FPU model inputs and
outputs to learn the conditional probability tables for a national
tradeoff analysis (goal program).
Reports Use goal program and other reports to understand similarities
and differences between alternatives and their impacts.
Budget Decisions Manages the identification of alternative to use for
implementation, ID each FPU’s program component selected.
Implement Decision After allocation, record funding levels for FPUs, communicate
to the FPUs.
The business process layer implements business processes by choreographing finer-grained
services as defined in the services layer. FPA generally choreographs services through Java
code. FPA defines “local” services, but the pattern can be adapted to use more complete
(remote) service definitions. This preserves the potential for other systems to use other
choreography technologies, such as BPEL.
The components identified in the tables above use the following design components/pattern:
29 of 50
Figure 18 Business process design elements
This pattern allows the “service consumer” (the business process) to use a service without
needing to know the technical details of how the service is built or accessed. Different business
processes can use the same service and transform (or “adapt”) the results as needed, without
modifying the component that provides the service.
5.3.2.3 Service Layer
The service layer is a collection of “service specifications”. Each service is a contract between
consumer(s) and provider(s). It is not an operational layer, but rather a “semantic” layer. It
decouples the business process realm from stand-alone IT-centric business functions and
tasks.
Consumers and business processes access and integrate these well-defined services to build
complex functions. Service components “provide” these services. Services can be identified “top
down” or “bottom up”. As the name suggests, top down analyzes the modeled business
processes (in the business process layer “above” the services layer) to identify services
supporting the business need. Bottom up considers existing IT capabilities and well-understood
domain components that might be useful in a solution. FPA primarily uses top down, starting
with the business use cases (FPA’s business models). Bottom up is also used where the fire
domain pieces are better understood than the ultimate consuming business process.
As part of the agile development process, “service identification” is ongoing. A list of current and
some candidate services follows:
Service Purpose
Business Process Program options, review and submit of FPU analyses
Common Common entities like analyses, FPU team data, FMGs, fuels and other
GIS
PM Access and report on the PMs and significant inputs - HVR, WUI,
“damaging” thresholds
FES Historic data inputs and fire event scenario creation and reports
Initial Response Significant inputs, behavior, and output/reporting related to IRS
Large Fire Significant inputs, behavior, and output/reporting related to large fire
Prevention Significant inputs, behavior, and output/reporting related to prevention
Goal Program Significant inputs, behavior, and output/reporting related to the goal
program
Table 11 FPA service identification
30 of 50
For now, these services will generally be “local” services, built by and for FPA. However, these
services could be consumed and adapted by (potentially) many business processes or even
other systems. This architecture positions FPA to (potentially) expose such services to other
federal fire IT systems. When or if such sharing occurs, governance of the service definitions in
this layer becomes more important – the impacts of changes then reach beyond FPA.
5.3.2.4 Business Services Layer
The business services layer contains atomic, relatively autonomous components. Among these
services are the scientific models that are invoked by the business process layer. The
separation of the business process from the simulation models will support modular use of the
scientific components and concepts. The simulation models themselves will be encapsulated as
components, with well-defined interfaces and dependencies. This will support future
enhancements and a pluggable model architecture.
Figure 19 Business service integration design elements
Components within this layer are “service providers”. The diagram above includes the lower half
of the service integration pattern described in 5.3.2.2 Business Process Layer. This is the
“service provider” side of the pattern, which exposes and adapts components for use as
“services”, and is applied between service providers and consumers. This pattern isolates the
routing and adapting, so the component does not need to be rewritten to support new
consumers. The “provider router” is the entry point to service components, and the “published
service” is part of the services layer (discussed previously).
Components within this layer also use the “service component architecture” (SCA) pattern,
which provides a proven, repeatable approach for creating “service” components. The SCA
focuses on the internal structure of the service component, the entities that must be present to
provide proper separation of responsibility in the delivery of the service component, and how
they interact together to fulfill a service component.
A “contract” defines the interface (inputs needed). A “mediator” represents the component, and
is defined to allow its capabilities to be exposed as services. It locates and choreographs a set
of domain objects to do the processing needed to fulfill the contract. The mediator “micro-
manages” the flow of objects within the component. “Domain objects” in the pattern represent
data like a fire resource or a historic record. The mediator avoids being tied too tightly to specific
domain objects by using a “factory” (another pattern) to retrieve them. The SCA pattern is
diagrammed below.
31 of 50
Figure 20 Service Component Architecture (SCA) pattern
Business services are the “building blocks” for FPA. Key components in the business service
layer are listed in the following table.
Table 12 Business services layer components
Category Component Purpose
Business Process Management Options Manage PV,FL, and IR options; process of submitting for
Review and Submit national; Range of budget options for national (Multi-
Multi-FPU Options FPU) analysis
Common Bus Svcs Analysis Miscellaneous process related entities; “Fuels” is not a
FPU Team model per se, but rather a key input to several other
FMG models. Fuels are described as part of the business
Fuels process used to prepare and run the simulations.
PMs PMs Process raw simulation results into distributions, useful
HVR, WUI for reports and PM derivations; derive PMs
FES Fire Event Scenario Process historic data to derive a modeled stochastic fire
Historic Fires and weather scenario.
Historic Weather
GP Goal Program Provide tradeoff insight intra-PM (national level only).
IRS IRS Model Model fire resources and dispatch logic against the
Dispatch Location stochastic fire scenario. Result is IA success.
Fire Resource
FWA
IRS Reports
LF Large Fire Model Calculate large fire probability and costs, using escapes
FSim from IRS and other large fire inputs.
LF Statistical
LF Reports
Stratified Cost Index
PV Prevention Model Modify human caused ignitions for a given fire scenario
32 of 50
Category Component Purpose
and prevention program.
The simulation model elements are key FPA components, and are discussed in more detail in
the following sections.
5.3.2.4.1 Fire Event Scenario Component
The Fire Event Scenario (FES) component encapsulates the process of generating IRS’s
stochastic fire scenario. It interacts with Historic Fire and Historic Weather components. The
event scenario model itself analyzes this historic data to generate a large number of “model
year” fire scenarios.
The FES model also uses other services, for instance to access fuels and topography to model
fire behavior. The “Run Models” business process that uses this service will itself identify the
fuels and prevention programs that lead to differing behavior and occurrence scenarios.
5.3.2.4.2 Initial Response Component
The Initial Response (IR) component encapsulates the initial attack effectiveness of an IR
organization. At the core of the model is the containment algorithm. The model uses many
services within the IR realm.
The “Run Models” business process uses the IR service to evaluate various IR organization and
dispatch logic “options”. The business process also manages other inputs that vary with each
invocation of the model, such as the Fire Event Scenarios that change with different fuels and
prevention options.
5.3.2.4.3 Large Fire Component
The Large Fire (LF) component encapsulates the calculations of burn probability on the
landscape, as well as the large fire suppression cost model. Burn probability is derived in two
steps. First a computationally intensive behavior model is run for selected inputs. This is the
FSim simulation. Then a regression analysis and resulting parameterized equation model is
used to provide many more large fire “samples” to derive the burn probability. This is the LFStat
model.
The FSim simulation integrates several components, some of which are shown in the following
diagram.
33 of 50
Figure 21 FSim overview
The statistical model processes the FSim output. The “Regression Function Calculator” is a
somewhat manual process – a statistician uses a desktop statistics package (SAS) to derive the
coefficients (unique for each FPU) for the statistical model’s large fire equation.
Figure 22 LF statistical model overview
This regression equation can then be used to generate a robust sample set to describe the
distribution of large fire probabilities.
As with the FES and IR models, the Run Models business process choreographs the IRS
outputs and fire management options with this model to derive outputs for a range of program
alternatives.
34 of 50
5.3.2.4.4 National Analysis (Goal Program) Component
The National Analysis is a separate application from the FPU Analysis system. At its core, the
National Analysis evaluates tradeoffs using a multi-attribute Goal Program. The goal program
uses the PMs associated with FPU alternatives as primary inputs. Based on user-specified
priorities and constraints, the model selects one alternative for each FPU. Each collection of
constraints and priorities results in a distinct nationwide fire program alternative.
The National Analysis is built as a Microsoft Access application. The model runs in the COTS
AMPL interpreter, which invokes CPLEX.
Figure 23 Goal program components
5.3.2.5 Data Integration Layer
The data integration layer provides access to the underlying entities in the database. The
Integration Mediator Function is a specialized kind of “service component” - the pattern parallels
the SCA patter in the Business Services Layer.
35 of 50
Figure 24 Data integrations design elements
The adapter and persistence service provide connections to low level databases. The
technology specifics of each data source are encapsulated here. FPA uses the Java
Persistence API (JPA). This is a standard (non-proprietary) framework to map Java objects onto
database entities. The result is a more flexible and maintainable system.
The business domain model and data warehouse considerations are discussed in the section
on data views.
The data is stored in an Oracle relational database. Spatial data will reside in SDE, and will be
accessed via FPA-defined map services. Some interim data, for instance the LCP files
produced for FSim, will be managed directly in the filesystem.
5.3.2.5.1 LANDFIRE
FPA (together with the WFDSS project) will maintain a “snapshot” of the FARSITE layers
available from LANDFIRE. This snapshot is needed for performance reasons, to avoid
transferring data directly from the LANDFIRE system every time a model is run, and because
FPA (and WFDSS) need updated LANDFIRE data, possibly before it is available from the
LANDFIRE project.
The LANDFIRE system is still the “system of record” to host the FARSITE layers and updates.
5.3.2.5.2 Other GIS
Some users will need special access to desktop GIS type capabilities on some servers at NITC,
to support these updates and other maintenance. See 5.4.4 Deployment Details for more
details.
5.3.2.6 Operational Systems Layer
The common services layer includes commercial packages, standard frameworks, APIs, and
other components on which the higher layers depend. This represents the “plumbing” of the
36 of 50
architecture. The details of the services layer belong in the technical architecture. This layer is
anticipated to include:
Figure 25 Operati0nal systems layer components
More detail on the specific applications in this layer can be found in 5.4.2 Software.
5.3.3 Collaboration Views
When the software structure described in the previous section is applied to implement user
stories, more dynamic views of the analysis model are needed. Based on the user stories, these
“realization” views help specify the interactions of the components described above. These
views parallel the Business Use Cases they are based on. Components collaborate across the
architectural layers to provide a complete system.
See the various High Level Design (HLD) documents for each component for details.
5.3.3.1 FPU Assess Situation / Input Data
In the “Assess Situation” use case, users prepare base data such as FMG boundaries, current
fuels, existing and potential resources, and the historic fire situation. This base data is constant
within an analysis, that is, it does not change from option to option. For instance, input data
includes lists of all fire resources and dispatch locations. Under “Develop Alternatives”, an IRS
option selects fire resources to include from this list. Note that Dispatch Logic does not vary
from option to option.
These are data management (create, read, update, delete) use case realizations.
5.3.3.2 FPU Define Objectives
The Define Objectives use case has been integrated into the Input Data user interface and
business process. In particular, the Highly Valued Resources (HVR, or “important resources”)
and WUI PMs need to know where these values are, and the FIL “damaging” thresholds.
Access to these values is via the PM service. Note that at the FPU level, the user cannot define
the locations of:
WUI: WUI location is nationally defined. FPU users define FIL “damaging” thresholds for
fires in the WUI.
HVR “important resources” (aka “gems”): HVR locations are nationally defined. FPU
users define FIL “damaging” thresholds for fires in HVR areas.
These are required to calculate the PMs.
37 of 50
5.3.3.3 FPU Develop Alternatives
The “Develop Alternatives” use case specifies how the user will define the fire program
alternatives that the system will evaluate. Each program component option gets persisted to the
database, where other components can access them. Fuels alternatives may be described with
respect to the “current” (LANDFIRE) fuels data. Similarly, the fire organization resources and
dispatch locations may reference the existing and planned resources created in Assess
Situation / Input Data.
5.3.3.4 FPU Assess Impacts
The “Assess Impacts” business use case integrates many elements of the system. This is the
core of the “FPU model”, embodying the Interagency Science Team’s vision of integrating
multiple models together.
Figure 26 Components in "Assess Impacts" - FPU
The Assess Impacts business process choreographs the execution of the models. Run Models
combines the various fire program component user-specified alternatives into all the possible
permutations, that is, fuels + initial response. Run Models then “batches” these combinations
into series of simulation instances. The execution sequence for each instance is described in
Figure 11 Summary of FPU level models (Note the UML provides other diagram types to
represent sequential behavior – for conciseness and clarity, this is a hybrid diagram). Each
model reads inputs from the business domain (data integration) layer, and writes results to that
38 of 50
layer as well. When the models finish, the PM component statistically processes the
“distribution:” of the PMs.
5.3.3.5 FPU Analyze Tradeoffs / Reports
Assess Impacts models the effects for each permutation of program component options
(prevention, fuels, and initial response). Analyze Tradeoffs provides insight into each
permutation as well as the differences between alternatives.
The user can select alternatives to compare. Goal programming in the National Analysis is
another way to perform inter-alternative analysis. The goal program weights, priorities, or other
settings used in a tradeoff analysis can be saved to support subsequent decision making.
5.3.3.6 FPU Review and Submit Analysis
This business process uses several services to support submission of an analysis to national,
and the regional and technical reviews. This includes business process services to manage the
submit states of analyses, and the reporting capabilities in all of the program and model
components.
5.3.3.7 National Overview
The national system supports the business process outlined in 3.2 System Vision. The term
“national” is a special instance of a more general “multi-FPU” analysis.
The over-arching “Manage DSS Process” keeps track of the dependencies between the lower
level processes. The national multi-FPU “analysis” references the submitted FPU analyses and
manages various national options. A national “option’ specifies a budget level, other constraints,
and relative management priorities. These options, together with the PMs for each FPU’s
submitted analysis, are the inputs for the goal program. For each national option, the GP
identifies a single FPU alternative for each FPU. The national business process specifies that
the national interagency budget team can use this collection of national options to inform the
budget request.
5.3.4 Design Model Views
Design views are developed during development iterations for each component. In the agile
methodology, “big design up front” is discouraged. To remain agile, a project must keep the
“cost of change” low. Agile practices support this by creating design model artifacts only when
and if they support the short-term creation of running code. That said, many of these artifacts
are available in the FPA document repository.
5.4 Deployment Views & Technology Plan
To support many of FPA’s architectural goals, constraints, and non-functional requirements, the
deployed system is server-based and multi-tiered. The database is in a central location, so all
users have a common view and “rollup” reports can easily access constituent data. See the
appendix for performance, availability, and storage analyses supporting the non-functional
availability and performance objectives.
FPA has multiple deployment sites which represent different stages of development. While the
software artifacts remain the same at each site the software architecture enables the execution
environment to change. Thus, each site can have a different deployment configuration based on
performance and scalability requirements as well as available hardware resources. The sites
currently consist of:
39 of 50
Boulder development
Boulder QA
NITC staging
EROS production
The selected production hosting site is the Department of Interior EROS Data Center. This
provides good connectivity and continuity from the FPA PM hosting services. Many other federal
fire applications are hosted there, offering opportunities to share resources such as the
LANDFIRE snapshots in WFDSS.
FPA’s hardware configuration uses a tiered architecture. Users access the system over the
Internet, using common and secure protocols. See Figure 27 Server deployment overview
diagram.
Figure 27 Server deployment overview diagram
The web server is the entry point for the application. A load balancer manages two web servers
to avoid a single point of failure.
The application and integration tiers are protected behind a firewall. The bulk of the application
logic is deployed on the AIX Enterprise server. Other nodes are integrated using a high
bandwidth network segment, and/or shared network storage.
The availability requirements do not justify clustering the application and database servers. The
p-series architecture is reliable and scalable enough to meet the availability identified in the non-
functional requirements.
To support the processor-intensive large fire behavior modeling, the architecture allows multiple
FSim “Fire Behavior” servers. The FSim servers share data via NFS in network attached
storage. The IRS simulations can also (optionally) be distributed across back-end servers.
5.4.1 Network
The application will expose standard web ports and protocols to the Internet. These front-end
ports are required to access the web server. The firewall can restrict access to specific hosts
(particularly the web servers) as well as ports. Special firewall rules may be needed to provide
GIS data administration access to servers.
40 of 50
IBM manages the deployed systems using a VPN.. Access to other fire systems, such as
WFDSS, is managed within the hosting system cloud. Details are discussed in 5.4.4
Deployment Details.
5.4.2 Software
The software deployed is listed in the following table.
Software Name Software # of Processors Proc.Type Servers Installed Comments
Version instances On
ArcGIS Desktop 9.3 1 8 fpa-raven GFE
ArcGIS Desktop 9.3 1 8 fpa-crow GFE
ArcGIS Desktop 9.3 1 8 fpa-plover GFE
Cisco Fabric Manager 3.2 1 8 fpa-raven Comes with Cisco
switch. Software may
be added to fpa-crow
IBM Tivoli Directory 6.1 1 8 xSeries fpa-raven
Server (aka LDAP) 3550
IBM Tivoli Directory 6.1 1 8 xSeries fpa-crow
Server (aka LDAP) 3550
IBM WebSphere MQ 6.0.2.3 1 2 pSeries fpa-mocking (8
p550 CPU with fpa-
shearwater)
IBM WebSphere MQ 6.0.2.3 1 3 pSeries fpa-petral ( 4 CPU
p550 with fpa-finch)
Oracle Client 9.2.0.1 1 8 fpa-raven GFE
Oracle Client 9.2.0.1 1 8 fpa-crow GFE
Toad - Oracle GUI tool 8.5.3 1 8 xSeries fpa-raven
(3rd party product) 3550
Toad - Oracle GUI tool 8.5.3 1 8 xSeries fpa-crow
(3rd party product) 3550
IBM HTTP Server 6.1.0.15 1 8 xSeries fpa-grackle
3550
IBM HTTP Server 6.1.0.15 1 8 xSeries fpa-magpie
3550
ArcGIS Server 9.2 1 8 fpa-plover GFE (FPA GIS Server,
SAS Stat server, Cplex
GP server)
Cplex 10.2 1 8 fpa-plover Goal Programming
Server - licensed in
2004 @ NITC
Microsoft Access 2003 1 8 fpa-plover Goal Programming
Server
SAS Software - Stat, ? 1 8 fpa-plover Large Fire SAS Stat
Access Support & ? server
IBM WebSphere 2.1.1.2- 1 8 fpa-plover Large Fire SAS Stat
Community Edition 20090424 server
Tivoli Storage Manager 5.5 1 8 xSeries fpa-avocet
(see TSM worksheet for 3650
complete listing)
IBM WebSphere 6.1.0.15 1 8 xSeries fpa-raven Deployment manager
Application Server 3550
Network Deployment
(WAS)
IBM WebSphere 6.1.0.15 1 8 xSeries fpa-crow Deployment manager
Application Server 3550
Network Deployment
(WAS)
41 of 50
IBM WebSphere 6.1.0.15 1 2 pSeries fpa-mocking (8 WAS instances
Application Server p550 CPU with fpa-
Network Deployment shearwater)
(WAS)
IBM WebSphere 6.1.0.15 1 3 pSeries fpa-petral ( 4 CPU WAS instances
Application Server p550 with fpa-finch)
Network Deployment
(WAS)
Sun Common Array 3.0.4 1 8 fpa-raven Comes with hardware,
Manager i.e. already purchased.
May install on fpa-crow
Oracle Database 10.2.0.3 1 2 fpa-mocking (8 GFE
CPU with fpa-
shearwater)
Oracle Database 10.2.0.3 1 3 fpa-petral ( 4 CPU GFE
with fpa-finch)
ArcSDE 9.2 1 2 fpa-mocking (8 GFE
CPU with fpa-
shearwater)
ArcSDE 9.2 1 3 fpa-petral ( 4 CPU GFE
with fpa-finch)
Windows Server 2003 Service 4 8 fpa-raven, fpa- Ordered with hardware
Standard 32bit Pack 2 crow, fpa-grackle,
fpa-magpie (8
CPUs each)
Windows Server 2003 Service 2 8 fpa-plover, fpa- Ordered with hardware
Enterprise 32bit Pack 2 avocet (8 CPUs
each)
Windows Server 2003 Service 8 16 fpa-cougar, fpa- Ordered with hardware
Enterprise 64bit Pack 2 bobcat, fpa-
margay, fpa-lynx,
fpa-ocelet, fpa-
jaguar, fpa-
pheasant, fpa-
osprey
IBM WebSphere 2.1.1.2- 8 16 fpa-cougar, fpa-
Community Edition 20090424 bobcat, fpa-
margay, fpa-lynx,
fpa-ocelet, fpa-
jaguar
AIX 5.3 5.3.0.7 4 12 fpa-shearwater, Ordered with hardware
fpa-mocking, fpa-
petral, fpa-finch
Backbase Government purchased
Symantec Endpoint 11 25 All Windows Government purchased
Protection AV software servers
Table 13 COTS software
The primary application source code will be written using Java 5. Exceptions include the IRS
contain algorithm and FPA FSim, both written in C++. The National Analysis program is Visual
Basic in MS Access.
5.4.3 Hardware
The hardware nodes deployed for FPA are listed in the following table.
Assigned Hostname System Description Machine Operating Applications
Type/Model System
42 of 50
FPA fpa-ocelet.cr.usgs.gov IBM x3850 m2, 16 7141-MC1 Windows LargeFire SIM
processors(2.93ghz), 2003 Server
32GB RAM, 70GB Server Ent
disk 64bit
FPA fpa-jaguar.cr.usgs.gov IBM x3850 m2, 16 7141-MC1 Windows LargeFire SIM
processors(2.93ghz), 2003 Server
32GB RAM, 70GB Server Ent
disk 64bit
FPA fpa- IBM x3850 m2, 16 7141-MC1 Windows LargeFire SIM
bobcat.cr.usgs.gov processors(2.93ghz), 2003 Server
32GB RAM, 70GB Server Ent
disk 64bit
FPA fpa- IBM x3850 m2, 16 7141-MC1 Windows LargeFire SIM
margay.cr.usgs.gov processors(2.93ghz), 2003 Server
32GB RAM, 70GB Server Ent
disk 64bit
FPA fpa-lynx.cr.usgs.gov IBM x3850 m2, 16 7141-MC1 Windows LargeFire SIM
processors(2.93ghz), 2003 Server
32GB RAM, 70GB Server Ent
disk 64bit
FPA fpa- IBM x3850 m2, 16 7141-MC1 Windows LargeFire SIM
cougar.cr.usgs.gov processors(2.93ghz), 2003 Server
32GB RAM, 70GB Server Ent
disk 64bit
FPA fpa.osprey.cr.usgs.gov NTS vx50, 16 NSR5U8WOP Windows Large Fire Sim
processors(2.81ghz), 2003 Server
32GB RAM, 1TB Server Ent
disk 64bit
FPA fpa- HPC, 16 A580F-SATA Windows Large Fire Sim
pheasant.cr.usgs.gov processors(2.81ghz), 2003 Server
32GB RAM, 500GB Server Ent
disk 64bit
FPA fpa-plover.cr.usgs.gov IBM x3650, 8 7979-MC1 Windows ArcGIS Server
processors(2.83ghz), 2003
16GB RAM, 140GB Server Std
disk
WFDSS/FPA fpa-spectralogic- SpectraLogic T50 RX50-4-F-F-1
t50.cr.usgs.gov Tape Library
WFDSS/FPA fpa-p6- IBM x3550 7042-CR4
hmc.cr.usgs.gov
WFDSS/FPA IBM p550, 4 8204-E8A AIX 5.3 Oracle, SDE,
processors, 64GB WebSphere
RAM, 70GB disk
WFDSS/FPA IBM p550, 8 8204-E8A AIX 5.3 Oracle, SDE,
processors, 96GB WebSphere
RAM, 70GB disk
WFDSS/FPA fpa-raven.cr.usgs.gov IBM x3550, 8 7978-MC1 Windows Tivoli Directory
processors(2.33ghz), 2003 Server, WebSphere
4GB RAM, 70GB Server Std NDM, WFDSS
disk GeoServer
WFDSS/FPA fpa-crow.cr.usgs.gov IBM x3550, 8 7978-MC1 Windows Tivoli Directory
processors(2.33ghz), 2003 Server,
4GB RAM, 70GB Server Std
disk
WFDSS/FPA fpa- IBM x3550, 8 7978-MC1 Windows HTTP Server
grackle.cr.usgs.gov processors(2.33ghz), 2003
4GB RAM, 70GB Server Std
disk
WFDSS/FPA fpa- IBM x3550, 8 7978-MC1 Windows HTTP Server
magpie.cr.usgs.gov processors(2.33ghz), 2003
4GB RAM, 70GB Server Std
disk
WFDSS/FPA fpa-rose-kvm Rose Ultralink UL-V3
43 of 50
WFDSS/FPA Rose Xtensys XTS V2X32D8
WFDSS/FPA Rose LCD Rack CS 1U 19AZX
View QPTBAW2 R
XXXX
WFDSS/FPA ? Cisco 9124 SAN DS-C9124-K9
Multi-layer Fabric
Switch (16-4gb
ports)
WFDSS/FPA Sun 6140 Disk CSM200
Expansion Array, 16
SATA disks - 1TB
WFDSS/FPA Sun 6140 Disk CSM200
Expansion Array, 16
SATA disks - 1TB
WFDSS/FPA fpa-stk-6140 Sun 6140 Disk Array CSM200
Controller, 16 FC
disks - 300GB
WFDSS/FPA Great Lakes Server
Rack
WFDSS/FPA Great Lakes Server
Rack
WFDSS/FPA Great Lakes Server
Rack
WFDSS/FPA Great Lakes Server
Rack
WFDSS/FPA fpa- IBM x3650, 8 7979-MC1 Windows Domain Controller
albatross.cr.usgs.gov processors(2.99ghz), 2008
16GB RAM, 420GB Server Std
disk
Table 14 FPA hardware list
5.4.4 Deployment Details
The following diagram shows the FPA Deployment Model at the EROS production site.
Figure 28FPA Deployment Model
44 of 50
The execution environment supporting this is illustrated below.
Table 15 FPA deployment details
The various components are discussed further in the following sections.
5.4.4.1 Deployment Units
The FPA software architecture is service oriented style software model. The services are
loosely coupled and packaged as Java archives (JAR). Java archives are then combined into
Enterprise archives (EAR) to create deployment units that can be independently managed.
Each EAR provides one or more services that are common in nature. Some services are
deployed in a manner that supports direct interaction with the end user and therefore execute
synchronously with the user session. Other services are packaged so they can execute
asynchronously with respect to the user session.
5.4.4.2 Network
Selected FPA users may need exceptions to the general firewall rules. In particular,
administrators will need VPN access. Some GIS data managers may need VPN or ESRI
desktop-specific protocols and ports opened from the agency intranets.
45 of 50
FPA and WFDSS will share some data, e.g. LANDFIRE snapshots, as discussed in 5.3.2.5
Data Integration Layer. These will be in a common SDE database (in Oracle, on the SAN),
which is accessed via the ports and protocols identified above.
The networks inside of EROS must be gigabit Ethernet. Server-to-server and server-to-storage
communications on these segments will include frequent and large data transfers. In particular,
access to GIS services and data on the NAS will require a high-bandwidth network.
5.4.4.3 Web Servers
FPA uses two web servers. The second server is primarily a backup to avoid single point of
failure, and can secondarily support performance scalability.
5.4.4.4 Application Servers
The p-series servers host the production instance of the FPA logic server. Deployments here
follow the FPA CCB process.
To remain agile, the FPA project keeps a separate “staging” server. The FPA project has full
access to this system, avoiding the production-level policies imposed on the production system.
5.4.4.5 FSim Servers
The FPA FSim servers are specialized, high-performance multi-processor 64-bit Windows
systems. Only specialized users and other servers need access to these systems. FPA shares
some of these servers with the WFDSS project, and vice versa.
Note that WebSphere is priced per processor, and these are 16-processor machines. The
WebSphere cost could be prohibitive, so these machines use WebSphere “Community Edition”.
The NAS (discussed below) helps address data sharing and some communication of this
integration.
5.4.4.6 Other Servers
IRS The IRS simulation can run on the business application servers, but may need to be
spread across multiple servers for performance reasons. This may be a good use of
the x-series servers.
Oracle The AIX servers that host the application servers will also host Oracle.
GIS The ArcGIS desktop and ArcGISServer components should run on Window servers,
per ESRI recommendations.
LDAP The LDAP server also hosts the WebSphere deployment manager. It is possible that
in the future the interagency fire applications will share an LDAP service. FPA can
support this direction, but is designed to manage its own LDAP server.
5.4.4.7 Storage
The primary storage subsystem is a SAN. Oracle runs on servers attached via FibreChannel to
the SAN. The SAN hosts Oracle data, including the SDE instances (GIS data, including
LANDFIRE data snapshots). SANs provide high-speed access, important for local (“chatty”)
database operations. Remote access to this data uses network and database mechanisms to
provide robust, general-purpose access, but can also clog the network on repeated, remote,
large transfers. The adapters and ongoing costs are somewhat expensive.
Some systems need a shared filesystem. This is via SAMBA access to the SAN, through a
SAMBA server. This provides a way for multiple, heterogeneous, remote systems to access
large volumes of data without stressing queue payloads or other possible performance
46 of 50
bottlenecks. For instance, multiple FSim servers require shared and repeated access to a very
large piece of data (the “landscape” file). The SDE access can be done once, with the resulting
output persisted to the shared filesystem. High-speed networks, like the FPA Interagency
network segment, give good performance for multiple, remote systems to share this data.
5.4.4.8 Security
See the non-functional requirements for many security details. The Security Plan provides
management, operational, and technical controls details required for C&A. Key security points
are summarized here:
Network
o Sensitive network traffic will be encrypted with SSL.
Authentication, authorization
o Access will be controlled via userid/password pairs
o Authorization will be role based
o Userids and roles will be managed via LDAP, with roles represented as “groups”
o Access to the database is via the application code. Direct connect access to the
database is limited to maintenance and administration users.
5.5 Data Views
The business domain data model reflects the decision support business process and the
scientific models’ needs. The data organization is represented in the packages in the following
picture.
The data model leverages enterprise data sources and “systems of record” where reasonable. It
is necessary to replicate some of this data, for performance and processing purposes. In
general, the FPA system avoids large and repetitive uploads and downloads by hosting much of
the needed data on FPA servers.
6 Summary
This Software Architecture Document presents both the conceptual (“what”) and technical
(“how”) views of the FPA System. It identifies goals and objectives, requirements, stakeholders,
scientific models, high and low level architectural views, and other implementation details. This
document will evolve as the system requirements and issues evolve.
7 Appendix
7.1 References
FPA Interagency Science Team Report, DRAFT Jan 2007
FPA Business Use Cases, Feb-April 2007
FPA Non-Functional System Characteristics, August 2007
FPA Security Plan, February 2009
7.2 Architectural Decisions
INDEX:
1. Use geospatial technology.
47 of 50
2. Incorporate many specific technologies identified by the Interagency Science Team and
others.
3. Implement as an enterprise application.
4. Use service-oriented layers.
5. Implement business services as service components.
6. Create a rich client interface that meets FPA usability standards.
7. Create a component based UI software architecture, based on JSF
Architectural Decision
Name Use geospatial technology.
ID AD 1
Problem Statement
Assumptions
Motivation
Alternatives
Decision
Architectural Decision
Name Incorporate many specific technologies identified by the Interagency
Science Team and others
ID AD 2
Problem Statement The IST recommended a complex system based on several existing
components.
Assumptions
Motivation Try to build on existing components and/or knowledge, rather than re-
invent.
Alternatives
Decision Use:
Bayesian belief and decision networks
Goal programming
Specific fire behavior/probability algorithms (LF FPA FSim,
statistical model)
Simulation similar to CFES2
Compatibility with EMDS/FS Fuels Prioritization outputs for fuels
alternatives (to be confirmed by FPA business leads)
Architectural Decision
Name Implement as an enterprise application
ID AD 3
Problem Statement Need to make development and deployment decisions
Assumptions
Motivation The benefits include consistent governance, easier maintenance,
auditing, better support (common view of the system and data), more
responsive updates and fixes, users not burdened with application
maintenance, less end-user data preparation, faster response to data
calls, etc.
Alternatives The national system has a smaller user base, and may not have as
compelling a case for this.
Decision The system will be an enterprise application, with centralized
48 of 50
application and data, user management, security,
installation/deployment, business rules, monitoring, and integrated
access to enterprise data sources.
Architectural Decision
Name Use service-oriented layers.
ID AD 4
Problem Statement Need a general approach to support flexibility and independence in
development.
Assumptions
Motivation Although the FPA design is not specifically targeting an SOA
environment, this architecture is flexible, modular, and responsive in a
stand-alone application, and positions FPA to integrate with other
enterprise services.
Alternatives
Decision Use layers to separate business, technical, and scientific concerns. This
layering is based on an industry standard Service Oriented Architecture
(SOA) solution stack
Architectural Decision
Name Implement business services as service components.
ID AD 5
Problem Statement
Assumptions
Motivation
Alternatives
Decision
Architectural Decision
Name Create a rich client interface that meets FPA usability standards.
ID AD 6
Problem Statement FPA is a complex analytical system. A sophisticated interface will help
use and understanding.
Assumptions
Motivation
Alternatives
Decision As agreed in the BP/UI meeting on 8/30/07, use standard JSF
components as much as possible. Write custom behaviors only when
the benefit outweighs the extra development and maintenance efforts.
Architectural Decision
Name Create a component based UI software architecture, based on JSF
ID AD 7
Problem Statement We need rich functionality but need to reduce the development and
maintenance effort associated with custom code.
Assumptions The component model of JSF will support rapid development, and can
be customized and integrated with AJAX as needed
Motivation
Alternatives 1. write custom JS and AJAX, providing great flexibility
49 of 50
Decision Create a component based UI software architecture that meets the
following criteria:
1. minimizes customization
2. responsive to agile methods
3. provides a standard framework for enterprise software
integration
4. ease of maintenance
5. reduces training required on UI technologies (js, CSS, xml, xslt,
AJAX, .. etc)
50 of 50