OASIS Phase II Approaching the Problem
description
Transcript of OASIS Phase II Approaching the Problem
©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?