Business Practices for Open Access Same-Time Information Systems (oasis) Standards & Communication Protocols Business Practices Requirements




старонка11/11
Дата канвертавання24.04.2016
Памер0.7 Mb.
1   2   3   4   5   6   7   8   9   10   11

002-4.5 INFORMATION SUPPORTED BY WEB PAGE
When a regulatory order requires informational postings on OASIS and there is no OASIS S&CP template to support the postings or it is deemed inappropriate to use a template, there shall be a reference in INFO.HTM to the required information, including, but not limited to, references to the following:


    • A common source of interconnection wide curtailment and interruption information, such as the NERC Transmission Loading Relief (TLR) web site.




    • Information related to the Transmission Provider's methodology for computing and application of Capacity Benefit Margin (CBM) and Transmission Reliability Margin (TRM). If the Transmission Provider does not use CBM or TRM in their assessment of Available Transmission Capability (ATC), that information shall also be in INFO.HTM.




    • The location of the list of system studies conducted.




    • Information on requesting the text file of the tariffs and service agreements.




    • An exception to this requirement is specified in Section 002-4.6

For the purposes of this section, any link to required informational postings that can be accessed from INFO.HTM would be considered to have met the OASIS posting requirements, provided that the linked information meets all other OASIS accessibility requirements.
002-4.6 INFORMATION UNDER STANDARDS OF CONDUCT LINK
The Transmission Provider shall establish a link entitled “Standards of Conduct,” located on the OASIS home page at the Transmission Provider’s registered URL address.
The following types of information, as found in Standards of Conduct for Transmission Providers, Order 2004, 105 FERC ¶61,248 (2003);order on reh’g, Order 2004-A, 107 FERC ¶61,032; order on reh’g, Order 2004-B, 108 FERC ¶61,118 (2004); order on reh’g, Order 2004-C, 109 FERC ¶61,325; order on reh’g, Order 2004-D, 110 FERC ¶61,320, and 18 CFR §358 should be accessible from the Standards of Conduct link.
Emergency Circumstances Deviations (§358.4(a)(2))
Marketing and Energy Affiliate List (§358.4(b)(1))
Shared Facilities (§358.4(b)(2))
Organizational Charts and Job Descriptions (§358.4(b)(3)(i))
Common Employees (§358.4(b)(3)(iii))
Potential Merger Partners (§358.4(b)(3)(v))
Transfers1 (§358.4(c))
Information Disclosure2 (§358.5(b) (3))
Voluntary Consent to Share Non-Affiliated Customer Information (§358.5(b)(4))
Discretionary Actions under Tariff 3 (§358.5(c)(4))
Discounts4 (§358.5(d))
Chief Compliance Officer (§358.4(e)(6))
Written Procedures for Implementation (§358.4 (e)(3))
These items shall appear in the order specified above and before any other items which may be required as per specific FERC direction or local business practice. Posting of the cites noted in the parentheses is optional. Access to some of the information found under the Standards of Conduct link above may require the user to register with the individual OASIS sites according to WEQ -002-3.1
002-5 PERFORMANCE REQUIREMENTS
A critical aspect of any system is its performance. Performance encompasses many issues, such as security, sizing, response to user requests, availability, backup, and other parameters that are critical for the system to function as desired. The following sections cover the performance requirements for the OASIS Nodes .
002-5.1 SECURITY
Breaches of security include many inadvertent or possibly even planned actions. Therefore, several requirements shall be implemented by the TSIPs to avoid these problems:
a. Provider Update of TS Information: Only Providers, including Secondary Providers, shall be permitted to update their own TS Information.
b. Customer Input Only ASCII Text: TSIPs shall be permitted to require that inputs from Customers shall be filtered to permit only strict ASCII text (strip bit 8 from each byte).
c. Provider Updating Over Public Facilities: If public facilities are involved in the connection between a Provider and the OASIS Node, the Provider shall be able to update his TS Information only through the use of ASCII or through encrypted files.
d. User Registration and Login: All Users shall be required to register and login to a Provider's Account before accessing that Provider's TS Information.
e. User Passwords: All Users shall enter their personal password when they wish access to TS Information beyond the lowest Access Privilege.
f. Service Request Transactions: Whenever Service Request transactions are implemented entirely over OASIS Nodes, both an individual Customer password for the request, and an individual Provider password for the notification of acceptance shall be required.
g. Data Encryption: Sophisticated data encryption techniques and the "secure id" mechanisms being used on the public Internet shall be used to transfer sensitive data across the Internet and directly between OASIS Nodes.
h. Viruses: Since only data is being transmitted between the OASIS Nodes and the Users, viruses are unlikely to be passed between them. Therefore, TSIPs shall be responsible for ensuring that the OASIS Nodes are free from viruses, but need not screen data exchanges with Users for viruses.
i. Performance Log: TSIPs shall keep a log on User usage of OASIS resources.
j. Disconnection: TSIPs shall be allowed to disconnect any User who is degrading the performance of the OASIS Node through the excessive use of resources, beyond what is permitted in their Service Level Agreement.
k. Premature Access: The TSIP log shall also be used to ensure that Users who are affiliated with the Provider's company (or any other User) do not have access to TS information before it is publicly available.
l. Firewalls: TSIPs shall employ security measures such as firewalls to minimize the possibility that unauthorized users shall access or modify TS Information or reach into Provider or User systems. Interfaces through Public Data Networks or the Internet shall be permitted as long as these security requirements are met.
m. Certificates and Public Key Standards (optional): Use of alternative forms of login and authentication using certificates and public key standards is acceptable.
002-5.2 ACCESS PRIVILEGES
Users shall be assigned different Access Privileges based on external agreements between the User and the Provider. These Access Privileges are associated with individual Users rather than just a company, to ensure that only authorized Users within a company have the appropriate access.
The following Access Privileges shall be available as a minimum:
a. Access Privilege Read-Only: The User may only read publicly available TS Information.
b. Access Privilege for Transactions: The Customer is authorized to transact Service Requests.
c. Access Privilege Read/Write: A Secondary Provider shall have write access to his own Provider Account on an OASIS Node.
002-5.3 OASIS RESPONSE TIME REQUIREMENTS
002-5.3.1 TSIPs can only be responsible for the response capabilities of two portions of the Internet-based OASIS network:

  • The adequacy of the TSIP's internet interconnection(s) for reasonable high-volume utilization

  • The response capabilities of the OASIS Node functions to process interactions with Users


002-5.3.2 Measurement Criteria for Internet Connections

An OASIS node's Internet connection(s) should not exceed 60% sustained utilization. To determine the sustained utilization, TSIPs shall retain usage records and logs related to the Internet service.


002-5.3.3 Measurement Criteria for OASIS Node functions
It is required that OASIS query functions meet or exceed the response times listed below during the normal conduct of business.


Template or GUI equivalent

Average Response not fewer than:

90% of Responses not fewer than:

transstatus

100 rows/minute

10 rows/minute

transoffering

500 rows/minute

100 rows/minute

It should be recognized that during periods of minimal interactivity there might be heavier loading due to automated processes gathering larger volumes of data or due to OASIS node housekeeping services. The offloading of such discretionary demand should not be discouraged if it serves to make the OASIS more responsive during primary periods of customer activity.


To assess whether these performance capabilities are obtainable, an OASIS application shall collect and log pertinent statistics on an hourly basis about each invocation of the primary types of data queries on the Templates transstatus and transofferring. Statistics logged shall be the number of invocations per type of template, the service processing time to retrieve the information, format of the responses, and effective template data row count.
002-5.4 OASIS PROVIDER ACCOUNT AVAILABILITY
The following are the OASIS Provider Account availability requirements:
a. OASIS Provider Account Availability: The availability of each OASIS Provider account on an OASIS Node shall be at least 98.0% (downtime of about 7 days per year).
Availability is defined as:
% Availability = (1 - Cumulative Provider Account Downtime) * 100

Total Time
A Provider account shall be considered to be down, and downtime shall be accumulated, upon occurrence of any of the following:
1. One or more Users cannot link and log on to the Provider account. The downtime accumulated shall be calculated as:
Σ for affected Users of 1/n * (Login Time), which is the time used by each affected User to try to link and log on to the Provider account, and where "n" is the total number of Users actively registered for that Provider account.
2. One or more Users cannot access TS Information once they have logged on to a Provider account. The downtime accumulated shall be calculated as:

Σ for affected Users of 1/n * (Access Time), which is the time used by each affected User to try to access data, and where "n" is the total number of Users actively registered for that Provider.


3. A five (5) minute penalty shall be added to the cumulative downtime for every time a User loses their connection to a Provider's account due to an OASIS Node momentary failure or problem.
002-5.5 BACKUP AND RECOVERY
The following backup and recovery requirements shall be met:
a. Normal Backup of TS Information: Backup of TS Information and equipment shall be provided within the OASIS Nodes so that no data or transaction logs are lost or become inaccessible by Users due to any single point of failure. Backed up data shall be no older than 30 seconds. Single points of failure include the loss of one:


  • Disk drive or other storage device

  • Processor

  • Inter-processor communications (e.g. LAN)

  • Inter-OASIS communications

  • Software application

  • Database

  • Communication ports for access by Users

  • Any other single item which affects the access of TS Information by Users

b. Spurious Failure Recovery Time: After a spurious failure situation, all affected Users shall regain access to all TS Information within 30 minutes. A spurious failure is a temporary loss of services which can be overcome by rebooting a system or restarting a program. Permanent loss of any physical component is considered a catastrophic failure.


c. Long-Term Backup: Permanent loss of critical data due to a catastrophic failure shall be minimized through off-line storage on a daily basis and through off-site data storage on a periodic basis.
d. Catastrophic Failure Recovery: Recovery from a catastrophic failure or loss of an OASIS Node may be provided through the use of alternate OASIS Nodes which meet the same availability and response time requirements. TSIPs may set up prior agreements with other TSIPs as to which Nodes will act as backups to which other Nodes, and what procedure will be used to undertake the recovery. Recovery from a catastrophic failure shall be designed to be achieved within 24 hours.
002-5.6 TIME SYNCHRONIZATION
The following are the time requirements:
a. Time Synchronization: Time shall be synchronized on OASIS Nodes such that all time stamps will be accurate to within "0.5 second of official time. This synchronization may be handled over the network using NTP, or may be synchronized locally using time standard signals (e.g. WWVB, GPS equipment).
b. Network Time Protocol (NTP): OASIS Nodes shall support the Internet tool for time synchronization, Network Time Protocol (NTP), which is described in RFC-1305, version 3, so that Users shall be able to request the display and the downloading of current time on an OASIS Node for purposes of user applications which might be sensitive to OASIS time.
002-5.7 TS INFORMATION TIMING REQUIREMENTS
The TS Information timing requirements are as follows, except they are waived during emergencies.
a. TS Information Availability: The most recent Provider TS information shall be available on the OASIS Node within 5 minutes of its required posting time at least 98% of the time. The remaining 2% of the time the TS Information shall be available within 10 minutes of its scheduled posting time.
b. Notification of Posted or Changed TS Information: Notification of TS Information posted or changed by a Provider shall be made available within 60 seconds to the log. S&CP Version
c. Acknowledgment by the TSIP: Acknowledgment by the TSIP of the receipt of User Purchase requests shall occur within 1 minute. The actual negotiations and agreements on Purchase requests do not have time constraints.
002-5.8 TS INFORMATION ACCURACY
The following requirements relate to the accuracy of the TS information:
a. TS Information Reasonability: TS information posted and updated by the Provider shall be validated for reasonability and consistency through the use of limit checks and other validation methods.
b. TS Information Accuracy: Although precise measures of accuracy are difficult to establish, Providers shall use their best efforts to provide accurate information.
002-5.9 PERFORMANCE AUDITING
The following are the performance auditing requirements:
a. User Help Desk Support: TSIPs shall provide a "Help Desk" that is available at least during normal business hours (local time zone) and normal work days.
b. Monitoring Performance Parameters: TSIPs shall use their best efforts to monitor performance parameters. Any User shall be able to read or download these performance statistics.
002-5.10 MIGRATION REQUIREMENTS
Whenever a new version of the S&CP is to be implemented, a migration plan will be developed for cutting over to the new version.



1 According to WEQ -002-4.3.10.4 a template is required for this item.

2 According to WEQ -002-4.3.10.6 a template is required for this item.

3 According to WEQ -002-4.3.10.5 a template is required for this item.

4 According to WEQ -002-4.3.2.1 a template is required for this item.

Draft Recommendation for Modifications to OASIS S&CP reflecting addition of OASIS Implementation Guide
Draft as of 12/27/2006 Page of
1   2   3   4   5   6   7   8   9   10   11


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка