workshop overview

North Slope Decision Support SystemFirst Stakeholder Workshop

January 20-21, 2009Anchorage, Alaska

Workshop Overview

• Introductions

• Project description

• Workshop objectives

• Designing the NSDSS through usage scenarios

• Usage scenario 1: Lake withdrawal permitting

• Did we get it right?

• Usage scenario working groups

Introductions• Project Team

– Amy Tidwell, University of Alaska Fairbanks

– Bill Schnabel, University of Alaska Fairbanks

– Kelly Brumbelow, Texas A&M University

– Stephen Bourne, PBS&J

– Leslie Gowdish, PBS&J

– Erica Betts, University of Alaska Fairbanks

– Arun Aryasomayajula, Texas A&M University

– Jim Haleblian, Algoloma Systems

Introductions

• Stakeholder participants…

Project Description• We all have a stake in the North Slope

• Development of North slope resources requires careful planning that includes all stakeholders.

• The North Slope Decision Support System (NSDSS) will provide a common forum for North Slope planning and management.

• The initial NSDSS application centers on environmentally responsible oil and gas exploration.

• This is a 3 year project, funded by the DOE, National Energy Technology Laboratory.

Decision Support System

Project Description Anatomy of a Decision Support System

Information System

Natural Systems Models

Planning and Management

Project Description: Physical Plan

Alaska Data

Stores

On-Going Remotely

Sensed Data Collection

NorthSlopeDBEnterprise

GeoDatabase

National Data

Stores

On-going Field Data Collection

NorthSlopeDSSWorkbench

NorthSlope Stakeholders


Exploration Team


Oil Company Planners

NorthSlopeDSSWorkbenchResearch

Team

Cache

Cache

Cache

Workshop Objective

Alaska Data

Stores

On-Going Remotely

Sensed Data Collection

NorthSlopeDBEnterprise

GeoDatabase

National Data

Stores

On-going Field Data Collection


NorthSlope Stakeholders


Exploration Team


Oil Company Planners

NorthSlopeDSSWorkbenchResearch

Team

Cache

Cache

Cache

Define how to build the workbench.

What am I doing here????

• To help define the requirements for the workbench– What are the most important decisions?

– What is the existing process for making those decisions?

– Can the process be improved? How?

– What is the role of technology?

– How can the workbench facilitate the decision-making process?

– How will you use the workbench?

NSDSS Development Timeline

• Stakeholder collaboration throughout

• Outcomes of this workshop drive rapid prototype development of next 12 months

Education & Facilitation Team

Technology Team

Science & Engineering Team

Solution RequirementsFormulation

(1st Stakeholder Workshop)

Data Collection & OrganizationCollaborative

Testing & Refinement

(2nd Stakeholder Workshop)

Solution Development

WRPM Solution Design

Prototype Development

Initial Data Collection

CollaborativeTesting &

Refinement

(3rd Stakeholder Workshop)

Phase Three (12 months)Phase Two (12 months)Phase One (12 months)

Technology Transfer & Knowledge

Building

Workshops:PlanningResearch

Public Forum

Case Studies

On-going Research and Solution DevelopmentDocumentation: Papers, Reports & Recommendations

Documentation: Specifications,User Manuals

Documentation: Requirements

Designing the NSDSS through Usage Scenarios

Overview

• What is a Usage Scenario?

• Using Usage Scenarios to Design the NSDSS

• Usage Scenario #1: Lake Allocation Permitting

• Is the Usage Scenario right?

• Building System Requirements

What is a Usage Scenario?• Flow chart of multi-participant process

• Not a software algorithm – a “people algorithm”

• Created before software is considered

• Each usage scenario is focused on a real-world process with specific needs for decision support.

• Multiple Usage Scenarios are supported by the system – many with overlapping requirements.

• Goal is to define a sufficient number of usage scenarios to fully define the requirements for the system.

What does a Usage Scenario Look Like?


Actions


Grouped Actions (Meta-boxes)


Decisions


Documents


Actors (color-coding: blue = O&G Company, orange = State of AK)


• Show thumbnail of US#1• Explain Key – ie. Meta-boxes, processes,

documents, etc.

Desired Technology Platform

NSDSS Development Timeline

• Stakeholder collaboration throughout

• Outcomes of this workshop drive rapid prototype development of next 12 months

Education & Facilitation Team

Technology Team

Science & Engineering Team

Solution RequirementsFormulation

(1st Stakeholder Workshop)

Data Collection & OrganizationCollaborative

Testing & Refinement

(2nd Stakeholder Workshop)

Solution Development

WRPM Solution Design

Prototype Development

Initial Data Collection

CollaborativeTesting &

Refinement

(3rd Stakeholder Workshop)

Phase Three (12 months)Phase Two (12 months)Phase One (12 months)

Technology Transfer & Knowledge

Building

Workshops:PlanningResearch

Public Forum

Case Studies

On-going Research and Solution DevelopmentDocumentation: Papers, Reports & Recommendations

Documentation: Specifications,User Manuals

Documentation: Requirements

Using Usage Scenarios to Design the NSDSS• 4 Usage Scenarios identified thus far:

– US#1 – Lake Allocation Permitting– US#2 – Ice Road Planning & Permitting– US#3 – Infrastructure Planning (Project Level)– US#4 – Support for NSB Comprehensive Planning

• Stakeholder participation is crucial to identifying and developing Usage Scenarios to make NSDSS as useful as possible.

• This list can change if the stakeholders want it to.

Usage Scenario #1: Lake Allocation Permitting

• Fresh water withdrawals on North Slope require permits from State (and sometimes BLM)

• Permits written to ensure safe levels of withdrawal from each permitted lake

• Lake locations and permitted withdrawals are necessary inputs to ice road planning

• Role of NSDSS– Streamline existing permitting process– Facilitate water balance analysis– Enable long-term planning

• Let’s look at the flow chart…

Usage Scenario #1: Lake Allocation Permitting

NSDSS TOOL DEMONSTRATION

Is the Usage Scenario right?

• Are the meta-boxes correct? Do we need more/fewer/editing?

• Inspect each meta-box individually Completeness Checklist:

Appropriate stakeholders included Communication between stakeholders Document production Technology elements

Building System Requirements

• Functional Requirements What the software does…

• Non-Functional Requirements How the software behaves…

• Institutional Requirements Who uses and maintains the software…

Usage Scenario #1: Requirements & Refinement

Functional:

Present Maps of North Slope Landscape (Vector and Raster Data)

Present Geo-referenced Time Series

Provide ability to peruse data

Provide an ability to compare existing data with template

Provide an ability to enter templates for MPR analysis, WB analysis, Permit application, MPR study reports, WB study reports, permit document

Provide an ability to auto-populate analyses and reports according to templates

Publish MPR plan and report, WB plan and report, Permit application, permit document

Usage Scenario #1: Requirements & RefinementFunctional (continued):

Assimilate Collected Data for MPR Study

MPR Analysis: Calculate Vol, Ice Vol, Fraction of Under-Ice Volume, Determine if Fish are Sensitive, Ice-chip analysis, snow harvest analysis, allocation computation.

Assimilate Collected Data for Additional Study

Water Budget Analysis: Process Input time series for water budget analysis, Assign processed time series to terms in water budget equation, calculate water budget, assess safe yield.

Bind and Package Permit Application

Submit permit application


Non-Functional:

Security/Accessibility

User Friendliness, Ergonomics

Performance

Open-ness, API, Modularity

Technology (db formats, web/desktop, use of existing data systems)

Standardization – compatibility/integration with other systems

Scalability


Institutional:

Users and Roles

Maintenance and Updates

Funding (esp. after DOE grant ends)

Process Changes (Mechanisms for Proposals and Decisions)

Peer Review of Data and Models

Usage Scenario Working Groups