Conservation and Demand Management
Information Solution
Functional & Technical Requirements
Issue: 1.0
Issue Date: June 30, 2015
Page 1 of 53
Copyright © 2013 Independent Electricity System Operator. All rights reserved.
This document uses Business Requirements Template IESO_TPL_0073 version 3.0.
Page 2 of 53
Table of Contents
1. Introduction .................................................................................................................................. 4
1.1
Purpose .............................................................................................................................. 4
1.2
The Current Scenario ....................................................................................................... 4
1.3
CDM IS Project Objectives .............................................................................................. 5
1.4
Who Should Use This Document................................................................................... 6
1.5
Acronyms .......................................................................................................................... 6
1.6
How this Document Is Organized ................................................................................. 6
2. CDM IS Requirements................................................................................................................ 7
2.1
Functional Requirements ................................................................................................ 8
2.1.1
System Users .............................................................................................................. 9
2.1.2
Measures Management........................................................................................... 12
2.1.3
Program Administration ........................................................................................ 15
2.1.4
Conservation and Demand Management Plan Administration ....................... 18
2.1.5
Application Management ....................................................................................... 21
2.1.6
Settlements ............................................................................................................... 24
2.1.7
Monitoring Key Performance Metrics .................................................................. 27
2.1.8
Customer Interface .................................................................................................. 29
2.1.9
Reporting and Analytics......................................................................................... 33
2.1.10 System Configuration Tools .................................................................................. 36
2.2
2.3
Technical Requirements ................................................................................................ 38
2.2.1
Technical, Security and Access Control Requirements ...................................... 39
2.2.2
Integration Capabilities .......................................................................................... 46
2.2.3
System Administration ........................................................................................... 47
Training and Knowledge Transfer .............................................................................. 49
Appendix A - Customer User Sub-Groups .................................................................................. 51
Appendix B – Customer Application Lifecycle .......................................................................... 52
Page 3 of 53
1.
Introduction
1.1
Purpose
1
The purpose of this document is to specify the requirements for the Conservation and
Demand Management Information System (CDM IS). The document specifies technical and
high level functional requirements for the CDM IS solution.
2
This document will be used in conjunction with the Request for Proposal (RFP) to identify,
procure and implement a CDM IS solution that provides automation and electronic
information management related to Conservation and Demand Management (CDM)
programs in Ontario.
1.2
The Current Scenario
3
Ontarians have embraced conservation, and its growing role in managing electricity demand.
Conservation First is the guiding principle that now places conservation at the forefront of
Ontario’s energy planning and procurement processes, ensuring it is the first option to be
considered in planning for electricity needs.
4
The new Conservation First Framework (CFF) maps out Ontario’s energy conservation goals
over the next six years (2015-2020), emphasizing a coordinated effort within all stages of
energy planning, as well as more effective teamwork among sector partners, particularly in
support of local distribution companies (LDCs) and natural gas utilities.
5
The IESO’s conservation goal is a total reduction of 8.7 TWh of electricity consumption in
Ontario by December 2020 1.7 TWh to be achieved through conservation programs with
transmission-connected customers, and seven TWh from conservation programs delivered by
LDCs to distribution customers across the province.
6
CFF gives a much larger role to the province’s distributors; each LDC has been allocated a
share of the seven TWh target that they can pursue individually or in partnership with other
LDCs.
7
The IESO is providing tools, support and guidance to LDCs to help them meet their targets
through the development of a six-year CDM Plan. The plan allows LDCs to design their own
program offerings, giving them greater flexibility to align conservation programs to local
needs, and give customers more choice. This will result in both province-wide programs as
well as programs offered by only one or some LDCs. It will also ensure long-term, stable
funding to give LDCs the certainty they need to implement and deliver their programs. In
addition, new administrative requirements now mean the IESO has sole approval over plans
and program offerings, ensuring oversight while still streamlining processes.
8
The 1.7 TWh reduction target for transmission-connected customers will be delivered through
the Industrial Accelerator Program (IAP), which offers financial incentives to industrial,
Page 4 of 53
commercial and institutional customers directly connected to the electricity grid. Incentives
encourage the implementation of major energy conservation projects, such as process changes
and equipment retrofits.
9
The roles and responsibilities of the IESO and LDCs under the new framework are formalized
in the Energy Conservation Agreement (ECA), a legal document that has been executed with
each LDC. The ECA and its accompanying documents specify important terms such as the
data that must be shared between LDCs and the IESO, and the schedules for data sharing.
10
To learn more about the CFF and the ECA, visit the Conservation First Framework section of
the IESO website. To learn more about existing conservation programs, visit the
saveONenergy and Industrial Accelerator Program websites.
1.3
CDM IS Project Objectives
11
Provide a solution that enables the IESO and LDCs to create, collaborate on, and administer
CDM programs in support of the Conservation First Framework directive.
12
Enable the IESO and LDCs to manage CDM program participation processes.
13
Enable the IESO and LDCs to manage CDM program settlement processes.
14
Improve the experience of customers participating in CDM programs by improving existing
technology and giving users direct access to application data.
Page 5 of 53
1.4
15
Who Should Use This Document
This document is for the use of:
a. Vendors in understanding the requirements for the CDM IS and in preparing their
proposal for the CDM IS.
b. CDM IS project team (analysts and subject matter experts) to ensure they understand
the criteria for evaluating each vendor’s proposal.
c. The Information System Sub-Group in validating that the high-level needs of LDCs
have been represented.
d. Other IESO stakeholders (security and advisors) to ensure requirements are clearly
specified.
1.5
1.6
Acronyms
CDM
Conservation and Demand Management
CDM IS
Conservation and Demand Management Information System
CFF
Conservation First Framework
ECA
Energy Conservation Agreement
EM&V
Evaluation, Measurement & Verification
FCR
Full Cost Recovery
IAP
Industrial Accelerator Program
IESO
Independent Electricity System Operator
LDC
Local Distribution Company
OWASP
Open Web Application Security Project
P4P
Pay for Performance
SaaS
Software as a Service
How this Document Is Organized
16
The core functional and technical requirements have been presented in Section 2 of the
document.
17
These requirements have been categorized into separate required and recommended
priorities so that vendors may understand the relevance and importance of each requirement
to the IESO's business.
Page 6 of 53
2.
18
– End of Section –CDM IS Requirements
The CDM IS requirements have been categorized into a number of functional and technical
requirements for analytical and evaluation purposes.
The Functional Requirements categorizations are in Sections:
2.1.1
System Users
2.1.2
Measures Management
2.1.3
Program Administration
2.1.4
CDM Plan Administration
2.1.5
Application Management
2.1.6
Customer Interface
2.1.7
Settlements
2.1.8
Monitoring Key Performance Metrics
2.1.9
Reporting & Analytics
2.1.10
System Configuration Tools
The Technical Requirements categorizations are in Sections:
2.2.1
Technical, Security and Access Control Requirements
2.2.2
Integration Capabilities
2.2.3
System Administration
The Training and Knowledge Transfer requirements are in Section 2.3.
19
The requirements listed for each functional area are not intended to be exhaustive, but are
aimed at providing a high-level description of the major information and processing
capabilities needed to support stakeholders of Ontario’s Conservation and Demand
Management programs.
20
It is critical that all the functionality in the proposed solution provided be clearly described,
and that the proposal includes specific descriptions of the complete functionality. It is also
critical that where applicable, the vendor provides details for any previous experience
implementing the solution or functionality. During the evaluation of the proposal emphasis
will be placed on the functionality that meets the requirements to the highest degree as
described in this document.
21
It is the sole responsibility of the vendor proposing the solution to ensure that they fully
understand the functional and technical requirements. If any of the functional or technical
requirements are unclear or if the concept or requirement is not fully understood, it shall be
the vendor's responsibility to contact the IESO for further clarification as laid out in the RFP
document.
22
Comments should be provided for most requirements to explain how the functionality will
be met by the solution and to provide sufficient details and context in order to avoid
misunderstanding during evaluation. Response to these requirements will be used as the first
step in evaluating the vendor.
Page 7 of 53
2.1
23
Functional Requirements
Functional Existence Priority: denotes the importance of the functional requirement to the IESO.
Required: The requirement must be able to be satisfied in order to meet the objectives of the project.
Recommended: The requirement is optional but its inclusion increases the business value of solution.
24
Vendor Response: Vendor’s description of the current availability of one or more features that can be used to satisfy the
requirement, using the below coding:
Response Code
Description
Y – Existing
Feature is delivered as standard functionality and can be demonstrated by the vendor.
F – Future
Feature is not currently included but will be available in a future release. Please indicate expected release time
frame.
T – Third Party
Feature is provided by a third party vendor.
N – Not Available
Requirement cannot be met.
Note: For each question to which your response is not N, please describe how your solution delivers the requirement specified.
Note: It is assumed that any and all data saved in your solution will have a full audit trail (date/time and user recorded). If this is
not correct, please specify any data for which an audit trail will not exist.
Page 8 of 53
2.1.1
System Users
The solution must be able to support at least the following high-level types of system users:
1) Customer
A Customer is an electricity consumer in Ontario who wishes to participate in a conservation program. There are several
subgroups of customers, which are further described in Figure Figure 2-1 of Appendix A and the following text. Customer
users include both distribution and transmission-connected customers. Distribution customers are the direct customers of
LDCs and include both residential and non-residential customers. Transmission-connected customers are directly connected
to the IESO grid and are customers of the IESO. All customers should have the ability to create a customer profile in the
system and apply for relevant conservation programs by supplying the necessary application information.
2) Local Distribution Company
LDCs are responsible for the management, design, and delivery of CDM programs to distribution customers. LDC users must
be able to manage customer program applications, apply to a program on behalf of a customer with the appropriate customer
consent, submit CDM plans to the IESO for review, submit program business cases to the IESO for review, monitor their
performance against their CDM plan, and produce ad-hoc reports. Authorized representatives from each LDC should be able
to manage the individuals that are assigned to each of the roles that are applicable to their company.
3) IESO
The IESO is responsible for overseeing all CDM programs in the province, including supporting the delivery of CDM
programs to distribution customers by LDCs and delivering CDM programs to transmission-connected customers. Specific
IESO responsibilities include, but are not limited to: managing the measures library and program catalogue, reviewing and
approving CDM Plans from LDCs, reviewing and approving program business cases from LDCs, calculating payments to
LDCs for CDM program expenses, and producing aggregate reporting. Authorized representatives from the IESO should be
able to manage the individuals that are assigned to each of their applicable roles.
4) Service Provider
Service Providers are companies that have been contracted to deliver a program or provide a specific service on behalf of the
IESO or LDCs. Service Provider users should be able to perform functions on behalf on an LDC or IESO, upload data (e.g.
batch application information) into the system.
5) Channel Ally
Channel Allies are contractors, trades, retailers, distributors or manufacturers involved in the delivery of conservation
Page 9 of 53
programs. These individuals and organizations may be delegated by residential, non-residential or transmission connected
customers to manage applications on their behalf. Based on confirmed credentials, Channel Allies may also have exclusive
access to tools and resources to support customers. Channel Allies may also participate in programs as a direct customer and
provide data to the IESO or LDCs.
6) Gas Utility
Gas utilities provide natural gas to Ontario customers and are regulated by the Ontario Energy Board. Conservation First
encourages collaboration between gas utilities and electric utilities in the design and delivery of programs. Gas utilities may
manage programs applications, supply batch data and produce reports.
Please describe how your system would support these types of users, including how users are modelled in the system and the
options for delivering the capabilities that are described in the requirements.
Vendor Description:
Requirement
1
2
An administrator can manage user roles and
permissions, including creating new user
roles, modifying the permissions associated
with user roles, and deleting user roles.
Functional
Existence
Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Required
New users can be registered in the system.
Describe the different methods that can be
used to achieve this requirement.
Required
Page 10 of 53
3
Users must be able to delegate specific
responsibilities to other users in the system.
For example, a customer delegates
responsibility for submitting information
about a CDM program project to a channel
ally.
Required
Describe the capabilities that exist for
delegation of responsibility within the system.
4
Access to data must be restricted based on
user role and the company (e.g. LDC) that the
user represents.
Describe how the system limits user access to
only the information that they are allowed to
access and how role-based access can be
administered.
Required
Page 11 of 53
2.1.2
Measures Management
Measures are the specific means of achieving energy and demand savings, and often serve as the basis for the design,
implementation, and evaluation of CDM programs. The IESO has three primary types of measures available for use in programs:
Prescriptive Measures, Quasi-Prescriptive Measures, and Custom Measures. The primary differentiator between the three types of
measures is how energy savings are calculated.
Prescriptive Measures are electricity conservation measures which present deemed energy and demand savings using prescriptive
input assumptions (PIAs). These measures provide best available information and consistent conservation program assumptions
needed to estimate potential gross energy and demand savings. Each measure has set values that dictate the anticipated energy and
demand savings.
Quasi-Prescriptive Measures have varying resource savings estimates according to the technology or type of equipment and the
context in which they are used. It contains key, measure-specific inputs to estimate energy and peak demand savings for each
program participant. It provides a methodology that allows estimating resource savings for various scenarios rather than relying on
a fixed savings value for all scenarios. A Quasi-Prescriptive Measure approach will allow different parameters or variables (e.g.
facility operating hours) to be assumed to estimate different levels of resource savings for different retrofits in different customer
segments.
Custom Measures are available for more complex or innovative solutions not covered by prescriptive or quasi-prescriptive
measures, and not on the pre-defined list. Technology, equipment and system improvements are evaluated on their demand and
energy-performance. Incentives are paid after installation, and once the energy savings have been measured and verified.
Read more about IESO Measures and Assumptions.
All measures should be stored in a central measures library. The measures library should be able to store links to external equipment
databases where users can research specific pieces of equipment corresponding to a measure (e.g. EnergyStar®, DesignLights
Consortium TM). IESO users will manage the measures library by creating new measures, updating the data for existing measures,
and retiring expired measures.
If your product includes a Measures Library, describe the baseline capabilities that are available for managing the measures library
and how changes to the library will cascade into other functions provided by your product.
If a Measures Library is not part of the product, describe how measures can be captured as part of program design.
Page 12 of 53
Vendor Description:
Requirement
5
6
IESO users can create new measures, update
the data for existing measures, and retire
expired measures.
Vendor
Response Vendor Description
(Y/F/T/N)
Required
IESO users can configure the energy savings
calculation method for each measure.
Describe the ability to have calculated fields,
using formulas and variables, in your
system.
7
Functional
Existence Priority
Measures can be selected and included in
the design of a new program.
Required
Required
Describe how measures can be grouped or
selected to form the basis of a new program.
8
Measure data can be imported and exported
from the system.
Recommended
Describe the import and export capabilities
of the system.
Page 13 of 53
9
LDC users and members of the public can
initiate the creation of a potential new
measure by inputting information in a web
form and submitting it to the IESO for
review and approval.
Recommended
Describe how the solution can be used to
support the creation of new measures.
10
Measures can have one or more links to
external equipment databases.
11
Measures can have start and end dates that
determine whether the measure is eligible to
be included in programs or applications.
Recommended
Recommended
Describe how your system would allow
users to manage the measure lifecycle.
Page 14 of 53
2.1.3
Program Administration
Programs leverage one or more measures to achieve energy savings in one or more targeted customer segments. Programs provide
customers with tools, resources, training, information, and/or incentives to help manage their electricity usage.
As part of the Conservation First Framework, the IESO will support LDCs in developing CDM programs for all distribution
customers. The IESO and LDCs will also collaborate with gas utilities in designing programs. The IESO will also develop and
deliver programs for transmission-connected customers. Table 2-1 below outlines in greater detail the roles that the IESO and LDCs
will play in conservation program design, approval, and delivery for the two types of customers.
2-1 Program Design, Approval, and Delivery Roles by Customer Type
Customer Type
Distribution
Includes customers across each of the seven
existing customer segments (i.e. residential,
low-income, small business, commercial,
agricultural, institutional, and industrial).
Program Design
Program Approval
Program
Delivery
Province-wide programs will be
designed by LDC working groups.
Local or regional programs may be
designed and proposed by one or more
LDCs.
IESO will support LDCs with provincewide, local, and regional program
design.
The IESO will
provide final
approval for all
conservation
programs.
LDCs/IESO
Transmission-Connected
Includes customers connected directly to the
IESO-controlled grid.
IESO
IESO
Program Administration includes all of the capabilities required to configure new programs, maintain and enhance existing
programs, and retire programs. Program configuration should include identification of the metadata, transaction data, and the steps
required when applying and successfully completing the program. All programs should be available for viewing and reporting. The
IESO will assign role-based permissions to users performing Program Administration.
Page 15 of 53
Describe your system’s Program Management capabilities. What are the major features?
Vendor Description:
Requirement
12
13
IESO users can create new programs in the
system, update the data for existing
programs, and retire old programs.
LDC and IESO users can initiate the
creation and approval of new programs.
Functional Existence
Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Required
Required
Describe how your system can be used to
support program design.
14
15
Existing programs can be saved as a
template and used as a starting point when
creating new programs.
Recommended
Customer eligibility rules can be
configured for each program and will
control whether or not a particular
customer can apply to the program.
Recommended
Page 16 of 53
16
A new version of an existing program can
be created with changes to its configuration
(e.g. eligibility rules).
Required
Describe how your system would achieve
this requirement. Both versions of the
program must be able to run in parallel.
17
A list of all available programs can be
viewed by LDC users.
Required
18
Supporting documentation (e.g.
calculators, compliance rules and measures
and verification procedures) can be stored
with each program.
Required
Page 17 of 53
2.1.4
Conservation and Demand Management Plan Administration
Collectively, Ontario’s LDCs are responsible for planning cost effective ways to reduce seven terawatt-hours (TWh) of electricity
consumption by December 31, 2020. The IESO has allocated a portion of the total energy savings and budget to each LDC. To meet
energy savings targets, LDCs are developing their own six-year plans for delivering CDM programs to their customers.
Primarily, the CDM Plan outlines the conservation programs that each LDC intends to run over the next six years, including the
annual budget and anticipated energy savings for each program. LDCs can include a mix of province-wide, local, and regional
programs in a CDM Plan. Programs included in the CDM Plan can be in active, proposed, or pilot status. Supporting data, such as
cost effectiveness ratios and planned collaboration with other regional LDCs, is also included in the plan for IESO review.
For each program included in the CDM Plan, LDCs may choose between two types of funding models: full cost recovery or pay-forperformance. Under the full cost recovery model the IESO will reimburse all eligible costs and expenses incurred by LDCs for the
design, development, and delivery of their CDM Plan. In contrast, pay-for-performance programs will be paid based on a prespecified value for each verified kilowatt hour of electricity savings achieved.
CDM Plans can be developed individually or in partnership with one or more other LDCs. If LDCs pursue a joint CDM Plan, they
may reallocate the total budget and energy savings targets assigned to them by the IESO amongst themselves. The parties to a CDM
Plan may change over time due to LDC mergers or preference.
Plans may be updated and resubmitted by LDCs as often as needed. A revised plan must be submitted if the LDC wishes to make
changes to its program offerings (including the funding mechanism) or if the LDCs participating in the plan are changing. LDCs
may also elect to update a plan to reflect program performance or a revised understanding of market opportunities. Each time an
LDC makes changes to its CDM plan the new version must be reviewed and approved by the IESO before it is active.
The IESO will receive, review, and approve all proposed CDM plans and supporting documents (e.g. achievable potential tool, cost
effectiveness tool, supporting reports). It will also provide centralized customer service, technical support, market research, program
evaluation and measurement, and training to LDCs.
CDM Plan Administration includes all of the capabilities required to receive, review, approve, and manage CDM Plans.
Currently CDM Plan data is captured in a MS Excel file - the CDM Plan Template. To help complete the cost effectiveness sections of
the CDM Plan Template, LDCs have been provided with a Cost Effectiveness Tool, which is also a MS Excel file. Describe how your
solution would be able to support the direct capture and modification of this data without the use of MS Excel.
Page 18 of 53
Vendor Description:
Requirement
19
LDC users can submit CDM Plan data and
supporting documents to the IESO for
review and approval.
Functional
Existence
Priority
Vendor
Response
Vendor Description
(Y/F/T/N)
Required
Describe how your system can be used to
support the submission of CDM Plans.
20
Before a CDM Plan can be submitted to the
IESO, each participating LDC must complete
an authorization and declaration.
Required
Describe how your solution would achieve
this requirement.
21
22
Describe how your system would support
the review and evaluation of CDM Plans
across multiple IESO business units.
The solution must be able to support mergers
and acquisition of LDCs, including LDCs
that are participating in joint CDM Plans.
Recommended
Required
Describe how this type of change would be
supported by your system as it relates to the
CDM Plan.
Page 19 of 53
23
All changes to a CDM Plan (e.g. program
offerings, program budgets, etc.) must be
tracked and stored in the system.
Required
Describe how your system will audit changes
to CDM Plans.
Page 20 of 53
2.1.5
Application Management
Customer participation in CDM programs is tracked through applications. Applications are submitted directly by a customer for a
program that s/he wishes to participate in, by an LDC representative on behalf of a customer, by an IESO representative on behalf of
a customer, or by a channel ally on behalf of a customer.
An application contains data regarding the program, the customer, the measure(s) being implemented, the incentives to be paid to
the customer, and more. Depending on the program, the application may include data regarding one or more facilities. A facility is
the physical location where conservation measures are being implemented. The application will also contain data that will be used to
calculate the gross and net unverified energy savings.
Unverified gross energy savings are reductions in energy consumption that are assumed to have occurred through program
participation but have not been formally confirmed. Unverified gross energy savings are calculated by combining measure data (e.g.
the energy savings associated with a particular type of light bulb) with data from the application (e.g. how many light bulbs were
installed). Unverified net energy savings are calculated by applying further mathematical adjustments to the unverified gross energy
savings. The mathematical adjustment(s) used may involve measure and/or program data.
To verify the gross and net energy savings, the IESO performs site inspections for a sample of applications on a periodic basis.
Depending on the outcome of the inspection, the unverified gross and net savings may need to be adjusted and the values are
recorded as verified gross and net energy savings. The ability to calculate, track, and report on net and gross unverified and verified
energy savings in the system is a critical component to its overall success.
Application Management includes all of the capabilities required to create, review, approve, and modify applications throughout the
application lifecycle. Application Management will be performed by customers, channel allies, LDC users, and IESO users.
Describe your system’s Application Management capabilities. What are the major features?
Vendor Description:
Requirement
Functional
Existence Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Page 21 of 53
24
Customers, LDC users, IESO users, and
Channel Allies can create new applications,
enter application data, and add one or
more facilities to an application. Facilities
associated with an application can be in
one or more LDC service areas.
Required
Describe the different methods for creating
a new application in your system.
25
Each application must have a unique
identification number.
26
Supporting documentation can be
uploaded and stored with an application.
Describe how documents are stored in your
system, how documents can be organized,
and how access to those documents can be
controlled based on user roles.
27
Required
Required
Data regarding the measures being used as
part of an application can be entered and
tracked in the system.
Required
28
A facility can be associated with one or
more program applications.
Required
29
IESO users can enter information and
upload supporting documents related to a
site inspection of an application or specific
facility related to an application.
Required
Page 22 of 53
30
Multiple customer profiles can access and
edit an application. For example, if an
application has been submitted where a
company is the customer, multiple users
from that company can access the
application and make edits.
Required
Describe how your system supports
multiple accounts being associated with a
single customer.
31
All changes to an application should be
tracked and viewable in an audit history.
Required
Describe how your system will track and
store changes to applications.
32
33
Customers can authorize other users (e.g.
IESO, LDC, Channel Ally) to make changes
to an application on their behalf.
LDC and IESO users have the ability to
initiate and track interactions (e.g. emails)
with a Customer or Channel Ally regarding
an application.
Required
Required
Describe your system’s ability to support
and track communications.
Page 23 of 53
2.1.6
Settlements
The IESO is responsible for funding CDM programs for distribution customers through payments made to LDCs. This funding is
intended to cover the expenses that an LDC would incur as a result of designing and delivering CDM programs. Currently, the two
biggest expense types related to CDM programs are customer incentive costs and administrative costs.
Customer Incentive Costs: Customers are incented to participate in CDM programs through the offering of customer incentive
payments. The value of customer incentives vary based on the measures installed, the program, and the specific application of the
customer. Each LDC is responsible for paying incentives to customers who participate in CDM programs in its service area. For
transmission-connected customers, the IESO will pay incentive costs directly to customers. The system must be capable of
supporting LDCs and the IESO in making customer incentive payments to their respective customer groups, including: calculating
the value of the incentive payment, identifying when the payment is eligible to be processed, and identifying when the payment has
been sent for processing in an external financial system.
Administrative Costs: Administrative costs include all defined non-incentive expenses that an LDC incurs for the design,
development, and delivery of its CDM Plan and CDM programs. Examples of administrative costs include direct labour and
marketing.
For each program included in its CDM Plan, an LDC may choose how it would like to receive funding from two options: Full Cost
Recovery or Pay-For-Performance. LDCs can change the funding model for each program a maximum of one time.
Full Cost Recovery (FCR): The IESO will reimburse LDCs for all adequately documented customer incentive and administrative
costs. LDCs also have the option to receive prefunding for any or all of its FCR programs. Prefunding can be up to 25% of the first
full year’s budgeted amount for an FCR program. FCR programs that have resulted in verified energy savings will also be eligible for
incentive payments to the LDC at various points throughout the 2015 - 2020 Framework.
Pay-For-Performance (P4P): LDCs will receive rate-based funding for each program based on verified energy savings; customer
incentive and administrative costs will not be directly reimbursed. The rate paid for each program will be set out in its corresponding
Program Rules. For each P4P program, LDCs can choose to receive payment in the form of a single payment following verification of
net lifetime energy savings, five annual payments following annual verification of energy savings, or a number of periodic payments
following verification of energy savings at the same frequency as the payments.
For FCR programs, LDCs need to be able to indicate to the IESO when they wish to receive payment, and for which customer
incentive and administrative costs they want to be reimbursed. The IESO must be able to export payment data to the IESO’s Market
Page 24 of 53
Settlement System and record in the CDM IS the LDC payments that have been sent for processing.
Once per quarter, the IESO will perform a reconciliation of payments made to LDCs. The system should support the quarterly
reconciliation process by enabling the comparison of payments made to LDCs against relevant data in the system (e.g. customer
incentive costs, administrative costs, CDM Plan budgets) and highlighting any variances.
For additional details regarding funding, incentives, and reconciliation under the CFF, please see Article 4 of the Energy
Conservation Agreement and the Settlements Information Requirements Rules.
Describe how your solution can support settlements with customers and the LDCs, including the import and export of data with
external financial systems.
Vendor Description:
Requirement
34
35
The system must calculate the value of
customer incentive payments based on data
in the system.
LDC and IESO users must be able to
identify applications that are eligible to
have customer incentive payments
processed.
Functional
Existence Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Required
Required
Describe how your system can allow users
to identify and initiate payments to
customers as they become due.
Page 25 of 53
36
37
LDC and IESO users must be able to
indicate when a customer incentive
payment has been sent for processing in an
external financial system.
LDC users must be able to identify expenses
that are eligible to be reimbursed by the
IESO.
Required
Required
Describe how your system will allow LDC
users to initiate reimbursement from IESO
for specific costs.
38
LDC and IESO users must be able to import
and export financial data from the system.
Required
39
The system must be capable of calculating
performance-based incentive payments due
to LDCs, based on data in the system.
Recommended
Describe how your system can support the
IESO’s quarterly reconciliation of payments
made to LDCs.
Recommended
40
Page 26 of 53
2.1.7
Monitoring Key Performance Metrics
The total energy savings target and budget for the new Conservation First Framework has been allocated amongst the province’s
LDCs. LDCs have prepared CDM Plans that indicate, by program, how each LDC intends to achieve its energy savings and spend its
budget. In order to support LDCs in achieving their energy savings targets and managing their budgets, the system must provide a
means for LDC users to configure performance metrics and track progress.
IESO users must have visibility into how each LDC is tracking towards its targets as well as how all LDCs as a whole are tracking
towards the provincial goals.
IESO is looking for a solution that can be easily configured to support setting performance metrics and monitoring progress against
goals. Describe your solution’s capabilities to support setting and monitoring performance metrics.
Vendor Description:
Requirement
41
IESO and LDC users will need to define
performance metrics and goals for assessing
progress using information that is available
in the system.
Functional
Existence
Priority
Vendor
Response
Vendor Description
(Y/F/T/N)
Required
Describe how your system supports this
capability.
42
LDC users must have visibility into how they
are performing towards their own goals.
Required
43
IESO users must have visibility into how
Required
Page 27 of 53
each LDC is performing towards its goals.
44
IESO and LDC users must have visibility into
how all LDCs as a whole are performing
towards aggregate goals.
Required
Page 28 of 53
2.1.8
Customer Interface
The customer interface will be the main interface that Customers will use to register in the solution and create a profile, apply for
programs, check the status of applications, update their applications, and authorize Channel Allies to act on their behalf (if desired).
A graphic detailing the vision for the customer experience and application process is included in Appendix B.
When a Customer goes to the customer interface for the first time, they must have the option to register for an account and build a
customer profile. The profile should include information about the Customer (e.g. contact info, LDC service area, etc.) and the types
of programs that they might be interested in (e.g. residential, small business). Customers should also be able to enter information
about any facilities that they may have (e.g. home, business location).
The next step in the customer experience would be to explore the program offerings available to them. At this stage Customers
should be able to view information about the available programs and the customer incentives associated with each one.
From a list of programs, the Customer should be able to select a program to participate in and fill out an application form. When the
Customer submits the application, it should be sent to the LDC, IESO, or Service Provider (as per business rules) for review and
approval.
At any time in the process the Customer should be able to log in to their account (if one was created) to see the status of program
applications, the energy savings and incentives associated with each application, and authorize a Channel Ally to act on his/her
behalf (if desired). The Customer should be able to make controlled changes to applications, as dictated by business rules.
If authorized by a Customer, Channel Allies should be able to follow the same steps outlined above on behalf of that Customer.
Customers should find the interface intuitive, easy-to-use, and it should be easy for them to access help. Their experience should
leave them with a positive view of participating in conservation programs or at the very least they should not find it more difficult
than other online tools they typically access.
Describe your system’s customer interface. What are the main features?
Vendor Description:
Requirement
Functional
Existence Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Page 29 of 53
45
Customers can create a profile and
participate in programs through the system
via an online customer interface.
Required
46
Channel Allies can create a profile through
the customer interface.
Required
47
Customers and Channel Allies must agree
to legal terms of use before a profile is
finalized in the system. Agreement with the
terms of use must be tracked in the system.
Required
The system must validate the individual’s
identity (e.g. email confirmation) before a
profile can be finalized.
Recommended
Customers and Channel Allies can opt out
of receiving further communication from
the IESO and LDCs through the customer
portal in compliance with Canada’s AntiSpam Legislation.
Required
Customers can apply for programs by
creating an application, with or without a
profile.
Required
51
Customers can authorize a Channel Ally to
act on their behalf for an application.
Required
52
Channel Allies can initiate an application on
behalf of a Customer.
Required
48
49
50
Page 30 of 53
53
Applications submitted on behalf of a
Customer, or by a Customer without a
profile, must be validated (e.g. email
confirmation) by the Customer before
proceeding in the application process.
Recommended
54
Customers and Channel Allies can view the
status of each of their applications.
Required
55
Customers and Channel Allies can view the
energy savings associated with each
application.
Required
56
Customers and authorized Channel Allies
can update an application after it has been
submitted based on business rules. For
example, LDC users can “unlock” a specific
field if an error was made.
Required
Explain how your system can control fieldlevel access in the customer portal.
57
Describe the import and export capabilities
available as part of your customer interface.
Recommended
58
Describe the ability of your system to
comply with the Accessibility for Ontarians
with Disabilities Act.
Required
Describe the ability to configure branding of
the customer interface, including multiple
brands.
Recommended
59
Page 31 of 53
60
61
Describe the overall customer experience,
explaining what features will allow them to
view the tool as an enabler of conservation
and not a barrier.
Recommended
The language of the customer interface can
be toggled between French and English.
Recommended
Page 32 of 53
2.1.9
Reporting and Analytics
The CDM IS must allow users to generate both standard and ad-hoc reports, based on their permissions.
The Energy Conservation Agreement outlines four standard reports that must be provided by the IESO to LDCs on a regular basis:
The Province-Wide Participation & Costs Report must be updated and made available to each individual LDC on at least a monthly
basis. This report provides LDCs with information on overall program participation, energy savings, spending, and cost
effectiveness. Data will be aggregated at two levels: province-wide and individual LDC. Individual LDC data will be compared
against CDM Plan data. LDCs will only be able to see their own data at the individual LDC level.
The Value-Added Services Report must also be updated and made available to each individual LDC on at least a monthly basis.
This report provides LDCs with information on the value-added service participation data and costs they incurred in the preceding
month, based on participation volumes. Each LDC must only have access to data for participants that fall within their service area.
The data for this report will be received from external Value-Added Service Providers.
Once per quarter, a single Customer Satisfaction Report must be made available to all LDCs. This report provides LDCs and the
IESO with information on how satisfied customers are with conservation programs that they have participated in. The data for this
report will be received from external Market Research Service Providers.
The Verified Results Report is produced once per year and shared with LDCs. The primary purpose of this report is to share
verified electricity savings results with the LDCs and compare those results to CDM Plans. Similar to the Province-Wide
Participation & Costs report, this report contains data aggregated at both the province and LDC levels.
In addition to the standard reports described above, LDC and IESO users must be able to create ad-hoc reports. The data that users
have access to during reporting must be dictated by their role in the system and/or configured permissions.
Describe the standard and ad-hoc reporting capabilities of your solution as well as the ability to configure role-based dashboards.
Vendor Description:
Requirement
Functional
Existence Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Page 33 of 53
62
The reporting function will be used to
generate reports as well as analytics. Access
to configuration and transaction data is
important.
Recommended
Specify the data that is accessible to the
reporting function and any limitations that
may impact users.
63
Describe the ability to import and export
data from the system, including any
limitations.
Recommended
64
Confirm that access to reports is based on a
user’s role (filtered by access control).
Required
65
Data can be aggregated for reporting
purposes. For example, IESO users can
report on the total number of applications
by program for all LDCs.
Required
Describe the ability of your system to
aggregate and drill-down into data for
reporting and analytics purposes.
66
Describe the delivery options for automated
reports.
Required
67
Provide examples of standard preformatted reports and describe the
flexibility available for tailoring the reports
to meet a specific need.
Required
Page 34 of 53
68
How can users save report results to access
historical reports at a later date?
Required
69
Discuss how non-technical users can
generate reports from the system without
assistance.
Recommended
70
Role-based dashboards can be configured in
Recommended
the system.
71
Describe how branding and logos can be
included in reports generated from the
system.
Recommended
Describe how reports can be published on a
public website.
Recommended
72
Page 35 of 53
2.1.10
System Configuration Tools
The IESO is looking for a system that is flexible to changing business rules and needs.
Provide an overview of the system configuration tools that are available to system administrators.
Vendor Description:
Requirement
73
A system administrator can configure
customer-facing and internal system forms
(e.g. program application form).
Functional
Existence Priority
Vendor
Response Vendor Description
(Y/F/T/N)
Recommended
Describe how form configuration can be
completed by system administrators.
74
A system administrator can configure
calculated fields based on defined formulas
and data in the system.
Recommended
Describe how system administrators can
configure and update automatic field
calculations.
Page 36 of 53
75
A system administrator can configure data
validation on fields.
Describe how system administrators can
apply data validation and other business
rules to fields.
76
A system administrator can configure fieldlevel access based on user roles and
permissions.
Recommended
Recommended
Describe the ability to configure field-level
access for different users.
77
A system administrator can configure
automatic email notifications based on
business rules.
Recommended
Describe the ability to automate emails and
other notifications in your system.
78
A system administrator can create new
fields and add those fields to forms.
Recommended
Page 37 of 53
2.2
79
Technical Requirements
Functional Existence Priority: denotes the importance of the functional requirement to the IESO.
Required: The requirement must be able to be satisfied in order to meet the objectives of the project.
Recommended: The requirement is optional but its inclusion increases the business value of solution.
80
Vendor Response: Vendor’s description of the current availability of one or more features that can be used to satisfy the
requirement, using the below coding:
Response Code
Description
Y – Existing
Feature is delivered as standard functionality and can be demonstrated by the vendor.
F – Future
Feature is not currently included but will be available in a future release. Please indicate expected release time
frame.
T – Third Party
Feature is provided by a third party vendor.
N – Not Available
Requirement cannot be met.
Page 38 of 53
2.2.1
Technical, Security and Access Control Requirements
Requirement
Functional
Existence
Priority
81
The solution shall be capable of supporting
current generation Internet browsers.
Identify the internet browsers that are
supported by your solution.
Required
82
The system is accessible on mobile devices
(e.g. tablets).
Required
83
We require the ability to test changes to
configuration changes and the integration of
new conservation programs prior to releasing
them into production.
Describe how your solution would support
development and testing of configuration
changes.
Is a separate environment provided to
support testing?
Required
84
Data Protection
Required

How do you separate IESO data from other
customers' data?

Where do you store IESO data (including
Vendor
Response
Vendor Description
(Y/F/T/N)
Page 39 of 53
backups)?

Is data stored at your site encrypted? If yes,
what encryption method is used

What mechanisms are in place to ensure
data integrity?

How do you protect data that is in transit
with your system?

What are your data leak prevention
capabilities?

Can any third party (your service
providers) access IESO data, and if so,
how?

Can you ensure that all IESO data is erased
at the end of service?
85
Vulnerability Management

What is your vulnerability remediation
process?

How often do you scan for vulnerabilities
(assessment) on your network and
applications?

Show evidence of your vulnerability
management program.
86
Identity Management

Required
Required
Does authentication need to occur before
accessing your offering? If so, describe the
available options.
Page 40 of 53

Can you integrate directly with IESO
directories, and if so, how?

If you keep your own user accounts:
o
How do you secure user IDs and
access credentials?
o
How do you handle user churns
(e.g., provision and de-provision
accounts)?

Can you support Single Sign On (SSO), and
if so, which standards?

Can you support federation, and if so,
which standards?
87
Physical and Personnel security

Is there restricted and monitored access to
customer assets 24x7?

If dedicated infrastructure is desired, how
would it be isolated?

Do you perform background checks on all
relevant personnel? How extensive?

Do you document employee access to
customer data?
88
Application security

Do you follow OWASP guidelines for
application development?

Do you prescribe to any of the following
software development life cycle models?
Required
Required
Page 41 of 53
(e.g. SEI CMM, DOD-STD-2167A, MILSTD-498, J-STD-016, IEEE/EIA 12207,
ISO/IEC 12207, etc.)

Do you have a testing and acceptance
procedure for outsourced and packaged
application code?

What third-party components are in use in
your services?

What application security measures (if any)
do you use in your production
environment? (e.g. application-level
firewall, IPS, database auditing)
89
Incident response

90
Required
What is your procedure for handling a data
breach?
o
Can notification occur within an
IESO specified time period?
o
In what format are Data Breach
Incident Reports (DBIR) published
in (e.g., VERIS) and what
information do they contain?
Service Privacy

How do you protect digital identities and
credentials and use them.

What data do you collect about the IESO
and/or LDCs?
Required
Page 42 of 53
o
How is it stored?
o
How is the data used?
o
How long will it be stored?

Under what conditions might third parties,
including government agencies, have
access to IESO data?

Can you guarantee that third-party access
to shared logs and resources won’t reveal
critical information about the IESO?
91
Service Compliance

Do you have any Disaster Recovery (DR)
and Business Continuity planning
documents capable of being shared with
the IESO?

Where are your recovery data centers
located?

What service-level guarantee can you offer
under DR conditions?

Are there provisions, specifications or
metrics in the SLA for investigations?

How long do you keep logs and audit
trails?

Can the IESO have dedicated storage of
logs and audit trails, and if so, how?

Can you demonstrate evidence of tamperproofing for logs and audit trails?
Required
Page 43 of 53

Can you provide documentation of ISO
27001 compliance?

Can you provide documentation of a
Statement on Auditing Standards SAS 70
or Statement on Standards for Attestation
Engagements SSAE 16 audits?

What recourse actions (e.g., financial
compensation, early exit of contracts, etc.)
are available in the event of a security
incident?

Can we stipulate in the SLA that all IESO
data (or applications), including all
replicated and redundant copies, are
owned by the IESO?

In the event that the contract is terminated,
or the agreement comes to an end:

92
o
Will data be packaged and
delivered back to the IESO?
o
Will any remaining copies of data
be erased completely (including
from backups)? If so, how soon will
it happen?
Specify any fees that may incur at the end
of the service.
Service Availability

Required
What availability measures do you employ
to guard against threats and errors?
Page 44 of 53
o
Do you use multiple ISPs?
o
Do you have DDoS protection, and
if so, how?

Can you provide historical availability
data?

What are your scheduled downtime plans
(e.g. service upgrade, patch, etc.)?
93
Service Provider Audit Capability

Audit Logging Capabilities that include
but are not limited to activities of
Authentication, Authorization (privilege
changes), Modification (of core
components) and User Operations
(repudiation). Log records include date
and time stamps, name or unique ID of
event, specified object (user, policy, object,
etc.) and severity.

Ability to export logs, on a continuous
basis
Recommended
Page 45 of 53
2.2.2
Integration Capabilities
The proposed solution will need to be able to integrate with Service Provider, IESO and LDC processes as a minimum to enable
tracking of program and payment statuses. The integration capabilities and the automation requirements for each organization will
vary depending on their size and the complexity of the programs. The solution should offer multiple integration methods.
Requirement
94
Describe all of the integration methods that
your solution will support.
For each of the integration methods please
specify:

How the information that is sent to and
from the CDM IS is protected.

What mechanism is used to authenticate
that you are allowed to read or write on the
interface

Any third party software that will be
necessary to integrate with the CDM IS
Functional
Existence
Priority
Vendor
Response
Vendor Description
(Y/F/T/N)
Required
Page 46 of 53
2.2.3
System Administration
System administration includes the capabilities necessary to sustain the services being provided by the CDM IS. The vendor should
describe the various administrative roles associated with their solution and identify the specific roles that are applicable to the IESO
and LDCs. The following should be included:

User Administration

Monitoring service levels

System Maintenance

Backup and Recovery

Path Management

Job monitoring

Managing of Incidents and Problems

Managing changes to the systems
Requirement
95
Who is responsible for managing and
assisting users with system access issues (e.g.
resetting a user’s access profile)?
96
Does your system maintain an audit trail of all
actions performed by an administrator and is
the information available to the IESO?
Functional
Existence
Priority
Vendor
Response
Vendor Description
(Y/F/T/N)
Page 47 of 53
97
Do you provide an Application Programming
Interface that can be used by the IESO and/or
LDCs to monitor the status of the system and
batch jobs? If yes what information is
accessible from the API and what technology
is used?
Page 48 of 53
2.3
Training and Knowledge Transfer
The following training effort is required; any other vendor proposal shall be described in the comments.
Requirement
98
Functional
Existence
Priority
Vendor
Response
Vendor Description
(Y/F/T/N)
Initial Training
Do you do any knowledge transfer at the end
of the implementation?
Do you provide initial training of the system
in terms of system configuration and
application administration?
Required
Do you provide classroom based, hands-on
training with full documentation of
functionality?
99
Ongoing Training
Describe your web based training capability?
Required
Does your solution offer users “How to”
embedded videos within the key modules?
Page 49 of 53
100 The various types of solution users (as
identified within this document) will have
the knowledge necessary to fully utilize the
solution at go-live.
Provide description of your training plan for
the different types of users. Include a
description of the type of training for the
different user groups, and describe how you
ensure knowledge transfer to the various
solution users enables them to use the system
independently.
Required
101 Support material (e.g. user guides and
templates) will be available to IESO to
customize and use for ongoing training.
Describe the online and soft copy user
training and guides available to the IESO?
Required
Identify any limitations we will encounter
with regard to modifying such
documentation.
102 Does your solution have different levels of
system administrators?
Recommended
– End of Section –
Page 50 of 53
Appendix A - Customer User Sub-Groups
Figure 2-1 - Customer User Sub-Groups
Customers
Distribution Customers
Individuals and companies who are connected to the IESO grid via an LDC. LDCs
are responsible for designing and delivering CDM programs for customers in their
service area and managing the relationship with these customers.
Residential Customers
Individuals who wish to participate
in residential programs
Non-Residential Customers
Companies and businesses who wish to
participate in non-residential (e.g.
commercial, institutional, etc.) programs
Transmission-Connected
Customers
Companies who are directly connected
to the IESO grid and wish to participate
in tranmission-connected customer
programs. The IESO is responsible for
program delivery and customer
relationship management for these
customers
Page 51 of 53
Appendix B – Customer Application Lifecycle
Creation of User
Profile &
Registration
The customer is
presented with the
opportunity to register
in the system and
create a profile.
Customers have the
ability to authorize a
Channel Ally to initiate
program applications
on their behalf.
Program Discovery
Customers are
presented with a list
of CDM programs.
Customers may
explore program
information, estimate
potential incentives,
and request further
information from
their LDC or IESO (as
applicable).
Pre-Project
Application
Submission
Post-Project
Application
Submission
The customer selects a
program to participate
in and submits an
application.
If the application is
approved, the
customer completes
the project and
updates the
application with actual
project data.
Application
submission can be
done with or without a
customer profile.
Incentive
Payment
Eligible incentive
amount are
determined by the
LDC or IESO and
paid to the
customer.
Post-Project
Support
The customer is
presented with the
option to complete a
Customer
Experience Survey.
The customer may
be selected for an
EM&V site visit or
audit.
Supporting project
documents are also
submitted.
Application Change Order
Customers can make changes to project
information
Application Review & Approval
Authorized LDC and IESO users manage application review and
approval processes
Application Tracking
Ability for IESO and LDC users to track customer and application information
Page 52 of 53
– End of Section –
– End of Document –
Page 53 of 53