©2004 PJM 1

OASIS Phase IIApproaching the Problem

General Discussion on Strategy and PhilosophyAndy Rodriquez - PJM

Presented to the NAESB ESS and ITSFebruary 16, 2004

©2004 PJM 2

How did we get here?

• OASIS 1A• Fax Tagging• E-Mail Tagging• Electronic Tagging• XML Electronic Tagging

• OASIS Phase II/Electronic Scheduling ANOPR

©2004 PJM 3

Core Objectives

• Customer-driven Development• Incremental Value• Cost Effective• Market Design Neutral• Encourage “seamless” boundaries whenever possible• Leverage Existing Tools…

without being bound by those tools

©2004 PJM 4

How do we start?

• Begin with the ESC Use Cases• Evaluate and Define OASIS functionality• Identify Modular Components• Determine Architecture• Develop Approach

©2004 PJM 5

Architecture

• This should NOT necessarily be a discussion on technical issues

• Focus should be on deployment strategy that meets core objectives

• Identify modular groups where appropriate

©2004 PJM 6

Approach

• Should focus on incremental deliverables to provide ongoing value

• Staged approached to functionality will allow amortized cost burden to companies

• Can also be utilized to address regional diversity– If upgrades can be done on an incremental basis, we can

work to ensure backward compatibility where possible

©2004 PJM 7

Ongoing Efforts

• IDC – Next Generation– No dependence on tags

• CIM Market Extensions– Coordination between RTOs

• PJM/MISO Congestion Management– Quantifying internal dispatch

• Information Technology Council– Facilitated Checkouts, Other Initiatives

©2004 PJM 8

Collaboration

• Should encourage participation to meet openness goals and ensure coordinated attack – minimal duplication of effort– NAESB Groups

• Seams Collaborative• Information Technology Subcommittee

– NERC Community• Interchange Subcommittee• Transaction Information Systems Working Group• Operations Reliability Subcommittee• Interchange Distribution Calculator Working Group

– ISO/RTO Council• Information Technology Committee

©2004 PJM 9

What is OASIS (my thoughts)?

• A market-oriented solution that optimizes the market interchange scheduling function– This would be developed by NAESB

• A reliability-oriented solution that meets the needs of the functional model with regard to operational interchange scheduling– This would be developed by NERC

• A set of interfaces to allow for market activity within a ISO/RTO/TP– This would be developed by the ISO/RTO/TP, but would align

with the NAESB functions• A “market/reliability interface” between the two, called the

Interchange Authority, that would tie markets and reliability together– This would jointly be developed by NERC, NAESB, and the IRC

MarketScheduling

Node

MarketScheduling

Node

MarketScheduling

Node

TP A (Legacy TP) RTO B RTO C

OASIS 1ANODE(TSP)

E-TagApproval

Market System

Energy, TX, AS(TSP)

LMPCongestion

Management

TLRInterface

NERC ReliefAnalyzer

InterchangeAuthority

GPE PSE LSE

Legacy Bridge

Market System

Energy, TX, AS(TSP)

OtherCongestion

Management

OperationsScheduling

Node

OperationsScheduling

Node

OperationsScheduling

Node

CA A RTO B RTO C

OP2Connector

OP2Connector

OP2Connector

OP2Connector

NERC

NAESB

RTO/FERC

BA RA TO RA TO BA RA TO

Proposed Vision

©2004 PJM 11

Suggested Timeline

• Spring/Summer 2004 – Develop Functional Design Documents– Detailed Scope– ESC Use Cases

• Summer/Fall 2004 – Develop Strategic Architecture Plan– Modules– Compatibility plans and requirements

• Winter 2004 – Identify Implementation Plan• 2005 – Design Stage I Components• 2006 – Implement Stage I Components, Design Stage II

Components• 2007 – Implement Stage II Components, Design Stage III

Components• 2008 – Implement Stage III Components

©2004 PJM 12

Initial Phases

• Stage I– OASIS Phase I Legacy Bridge– E-Tag Legacy Bridge (replace Authority with limited IA

functionality)– IDC Architectural Split (Impact Calculator vs. TLR Process)

• Stage II– OASIS Phase II Functions– Legacy Bridge Upgrades– Operations Scheduling Tools (Functional Model)– Enhanced IA to Reliability Interface– IDC Next Generation

• Stage III– Electronic Scheduling– Market to IA Interface

©2004 PJM 13

Question

• Do we agree upon the core principles?– Customer-driven Development– Incremental Value– Cost Effective– Market Design Neutral– Encourage “seamless” boundaries whenever possible– Leverage Existing Tools without being bound by those tools

©2004 PJM 14

Question

• Does everyone agree with these next steps?– Functional Design Work

• Begin with the ESC Use Cases• Evaluate and Define OASIS functionality

– Identify Modular Components• Identify key components

– Determine Architecture• Group components logically based on dependencies

– Develop Approach• Build implementation plan for staged approach

©2004 PJM 15

Key Components

• Develop appropriate representation across the industry• Establish “governance” issues

– Identify leadership

– Determine other key liaisons and roles

– Set up meeting schedules

– Agree to vision and scope

– Establish milestones and deliverables

NAESB OASIS II Development Overview

Information Technology

Subcommittee

Electronic Scheduling

Subcommittee

OASIS II Structural

Design Task Force

OASIS II Implementation Task Force

ESC Use Cases

Vision and Scope

Structure Design

Document

Use CaseDocument

Functional Requirements

S&CP Documents

Business Practices

Implementation Plan

Joint OASIS Phase II

Implementation Task Force

FERC Filed Documents

©2004 PJM 17

Vision and Scope

NERCIS

NERCORS

NAESBESS STF

Visionand

Scope

IRC,Customers,

Others

Functional Model Vision – “Downstream of the IA”

Next Generation IDC Vision RTO Internal Systems

(Current and Future), General Guidance

Customer-driven focus – “Upstream of the IA”

Overall long-term vision – where do we

want to be?

©2004 PJM 18

Use Case Document

UseCase

Document

NERCTISWG

NERCIDCWG

Functional Model Component – “Operational Scheduling”

Next Generation IDC Functions

NAESBESS JOP2ITF

NAESBESS STF

NAESBITC SDTF

Business Analysis, Facilitation, Customer Focus

Detailed walkthrough of functionality, business logic

IRC,Customers,

Others

RTO Internal Systems (Current and Future), General Guidance

©2004 PJM 19

Functional Requirements

FunctionalRequirements

NAESBESS JOP2ITF

NAESBESS STF

NAESBITC SDTF

IRC,Others

RTO internal Systems (Current and Future)

Beyond Use Cases – “blueprints” for S&CP

Includes System Requirements

Documentation and Technical Guidance

©2004 PJM 20

Structure Design Document

StructureDesign

IRC,Customers,

Others

NAESBESS JOP2ITF

NAESBESS STF

NAESBITC SDTF

How do we want to organize the functional

pieces?

Business Analysis, Facilitation, Customer Focus

Logical Guidance, Priorities

©2004 PJM 21

Implementation Plan

ImplementationPlan

NERCIS

NERCORS

IRC,Customers,

Others

NAESBESS JOP2ITF

NAESBESS STF

NAESBITC SDTF

How do we roll everything out?

How do we coordinate with the Functional Model Implementation?

How do we coordinate with the Next Generation IDC? How can we bring in

new and existing systems?

Facilitation and Technical Guidance

©2004 PJM 22

S&CP

S&CP

NERCTISWG

NERCIDCWG

IRC ITC

NAESBITC

How do you build it?

How do we coordinate with the Functional Model Implementation?

How do we coordinate with the Next Generation IDC?

How can we integrate new and existing systems?

Facilitation and Technical Guidance

EPRI CME

What parts of the CIM can we leverage?

Vendors

What technologies can we leverage?

©2004 PJM 23

Business Practices

ImplementationPlan

NERCIS

NERCORS

IRC,Customers,

Others

NAESBESS

How do you operate it?

What criteria does NERC have we need to coordinate with?

What BP Standards can we agree to?

Facilitation and Technical Guidance

IRC Seams,NAESB Seams

Can BP Standards fix some seams?

©2004 PJM 24

Questions?