Right to Request Capacity Check Test and Test Protocol Sample Clauses

Right to Request Capacity Check Test and Test Protocol. The Buyer shall have the option, exercisable on no more than two (2) occasions per Contract Year, to require the Supplier, within ten (10) Business Days after written notice has been delivered to the Supplier, provided it is not during an Outage, to conduct a test (the “Capacity Check Test”), at the Supplier’s sole cost and expense, that may be witnessed by the Buyer or its Representative, to confirm the ability of the Facility to produce the Contract Capacity, as described below. The Capacity Check Test will be carried out in accordance with a test protocol (the “Test Protocol”) which will include the format of the report to be prepared in respect of the Capacity Check Test and which Test Protocol is to be prepared by the Supplier and submitted in writing to the Buyer for approval at least three (3) months prior to the Term Commencement Date. The measurements of the Capacity Check Test shall be made using high accuracy calibrated instruments and recording systems or Facility instrumentation, including tariff meters for Electricity acceptable to the Buyer, acting reasonably. Each Capacity Check Test consists of the Facility generating Electricity for four (4) continuous hours during a period designated by the Supplier on prior written notice to the Buyer in advance as a test period, subject to coordination and approval of the IESO, and shall be evaluated based on calculation‌ of the generator output at the Delivery Point net of any Station Service Loads in accordance with the Metering Plan. The Supplier acknowledges and agrees that the Contract Capacity, the Electricity output of the Facility and the Station Service Loads, as may be measured by the Capacity Check Test, shall not be adjusted for ambient weather conditions. For greater certainty, the Capacity Check Test shall be based on the Season 1 Contract Capacity, Season 2 Contract Capacity, Season 3 Contract Capacity or the Season 4 Contract Capacity, as applicable, depending on the calendar month during which the Capacity Check Test is conducted.
Sample 1
AutoNDA by SimpleDocs

Related to Right to Request Capacity Check Test and Test Protocol

  • ACCEPTANCE TESTS 11.1 If the Contract provides acceptance tests for Goods and/or the result of Services after their completion and/or delivery to the Purchaser, the acceptance shall only be considered as definitive when such tests have demonstrated the compliance of the Goods and/or the result of the Services to the requirements in the Contract.

  • Acceptance Testing At the time of installation of a LIS trunk group, and at no additional charge, acceptance tests will be performed to ensure that the service is operational and meets the applicable technical parameters.

  • System Upgrade Facilities and System Deliverability Upgrades Connecting Transmission Owner shall design, procure, construct, install, and own the System Upgrade Facilities and System Deliverability Upgrades described in Appendix A hereto. The responsibility of the Developer for costs related to System Upgrade Facilities and System Deliverability Upgrades shall be determined in accordance with the provisions of Attachment S to the NYISO OATT.

  • Right to Observe Testing Developer and Connecting Transmission Owner shall each notify the other Party, and the NYISO, in advance of its performance of tests of its Attachment Facilities. The other Party, and the NYISO, shall each have the right, at its own expense, to observe such testing.

  • Acceptance/Performance Test 4.7.1 Prior to synchronization of the Power Project, the SPD shall be required to get the Project certified for the requisite acceptance/performance test as may be laid down by Central Electricity Authority or an agency identified by the central government to carry out testing and certification for the solar power projects.

  • Service Specification The Parties have agreed upon the scope and specification of the Services provided under this Service Agreement in the Service Specification.

  • Random Testing Notwithstanding any provisions of the Collective Agreement or any special agreements appended thereto, section 4.6 of the Canadian Model will not be applied by agreement. If applied to a worker dispatched by the Union, it will be applied or deemed to be applied unilaterally by the Employer. The Union retains the right to grieve the legality of any imposition of random testing in accordance with the Grievance Procedure set out in this Collective Agreement.

  • Test procedure The engine speed shall be gradually increased from idle to the target engine speed, not exceeding the tolerance band of ±3 per cent of the target engine speed, and held constant. Then the throttle control shall be rapidly released and the engine speed shall be returned to idle. The sound pressure level shall be measured during a period of operation consisting of a maintaining constant engine speed of 1 second and throughout the entire deceleration period. The maximum sound level meter reading during this period of operation, mathematically rounded to the first decimal place, is taken as the test value.

  • System Access Control Data processing systems used to provide the Cloud Service must be prevented from being used without authorization. Measures: • Multiple authorization levels are used when granting access to sensitive systems, including those storing and processing Personal Data. Authorizations are managed via defined processes according to the SAP Security Policy • All personnel access SAP’s systems with a unique identifier (user ID). • SAP has procedures in place so that requested authorization changes are implemented only in accordance with the SAP Security Policy (for example, no rights are granted without authorization). In case personnel leaves the company, their access rights are revoked. • SAP has established a password policy that prohibits the sharing of passwords, governs responses to password disclosure, and requires passwords to be changed on a regular basis and default passwords to be altered. Personalized user IDs are assigned for authentication. All passwords must fulfill defined minimum requirements and are stored in encrypted form. In the case of domain passwords, the system forces a password change every six months in compliance with the requirements for complex passwords. Each computer has a password-protected screensaver. • The company network is protected from the public network by firewalls. • SAP uses up–to-date antivirus software at access points to the company network (for e-mail accounts), as well as on all file servers and all workstations. • Security patch management is implemented to provide regular and periodic deployment of relevant security updates. Full remote access to SAP’s corporate network and critical infrastructure is protected by strong authentication.

  • Loop Testing/Trouble Reporting 2.1.6.1 Think 12 will be responsible for testing and isolating troubles on the Loops. Think 12 must test and isolate trouble to the BellSouth portion of a designed/non- designed unbundled Loop (e.g., UVL-SL2, UCL-D, UVL-SL1, UCL-ND, etc.) before reporting repair to the UNE Customer Wholesale Interconnection Network Services (CWINS) Center. Upon request from BellSouth at the time of the trouble report, Think 12 will be required to provide the results of the Think 12 test which indicate a problem on the BellSouth provided Loop.

Time is Money Join Law Insider Premium to draft better contracts faster.