< 上一个 | 内容 | 下一个 >

Appendix A- Requirements


General CSIP Requirement

ID

Requirements

G1.

Each DER Client SHALL connect to the utility in one and only one scenarios.

G2.

Although outside the scope of CSIP, security SHOULD be used in all non-IEEE 2030.5 interactions between the Aggregators, site hosts, GFEMS, and DERs and other entities receiving or

transmitting DER related communications

G3.

For DER Clients that have an IEEE 2030.5 certificate, the GUID SHALL be derived from this

certificate (see section 5.2.1.2).

G4.

Implementers SHALL refer to each utility’s Interconnection Handbook for requirements related

to the creation, use or management of this identifier.

G5.

Aggregators and DER Clients SHALL support IEEE 2030.5 based grouping and full lifecycle management of group relationships as defined within Section 5.2.3 and within each utility’s

Interconnection Handbook or program/contract requirements.

G6.

Autonomous functions’ default settings SHALL be changeable via IEEE 2030.5 DefaultDERControl

communications.

G7.

Modifications to default settings SHALL occur immediately upon receipt and have an indefinite

duration.

G8.

Scheduling Autonomous and Advanced Power Values and Modes SHALL be controllable via IEEE

2030.5 DERControl events

G9.

Aggregators and DER Clients SHALL be responsible for assuring that all operations received from

the utility are processed in the appropriate time sequence as specified by the utility.

G10.

An Aggregator acting for its DERs and DER Clients SHALL be able to store at least 24 scheduled

DER control events for each DER.

G11.

In the absence of scheduled controls, DERs SHALL maintain a default control setting specified by

interconnection tariffs or the utility Interconnection Handbook.

G12.

Should there be a loss of communications, DERs SHALL complete any scheduled event and then

revert to default settings or as determined by the site host or tariffs/contracts.

G13.

When commanded in a manner where two or more operations are possibly in conflict, the interpreting system SHALL operate against the control operation which has the highest priority

subject to the systems capability, contracts and self-protection requirements.

G14.

If avoidance of conflicting commands is not possible, the more recently received command

SHOULD have precedence over the older command.

G15.

In either case, it SHALL be the responsibility of the aggregator or DER Client to decide how to

handle these two simultaneous controls.

G16.

For Aggregators communications, notifications and call backs (subscription/notification) SHALL

be used to limit system polling to the greatest extent practical.

G17.

To simplify communication requirements for Direct DER Communications scenarios, unless specified otherwise in utility Interconnection Handbooks or programs/contracts, all

communications SHALL be initiated by the DER Client (i.e., client-side initiation).

G18.

In Direct DER communication scenarios, the DER Client SHALL initiate communications with the utility according to a pre-defined polling and posting interval to ensure the DER has up to date

settings and the utility understands the operational state of the DER.

G19.

Unless specified in each utility’s Interconnection Handbook, default polling and posting rates

SHALL be as follows:



-Polling of DERControls and DefaultDERControls (Direct DER Communication)– every 10 minutes

-Posting monitoring information (Direct and Aggregator Mediated Communications)– every 5 minutes

G20.

For DERs with an external SMCU, the SMCU SHALL transfer the DER control to the generating

facility within 10 minutes of receiving the control from the server.

G21.

For DERs with a GFEMS, the GFEMS SHALL transfer the DER control to the DERs within 10

minutes of receiving the control from the server.

G22.

For DERs mediated by Aggregators, the Aggregator SHALL transfer the DER control to the DERs

within 15 minutes of receiving the control from the server.

G23.

Aggregators acting for its DERs and DER Clients SHALL have the capability to report the

monitoring data in Table 2.

G24.

Aggregators acting for its DERs and DER Clients SHALL have the capability to include the data

qualifiers in Table 3.

G25.

All measurement SHALL include a date-time stamp.

G26.

Unless otherwise specified in each utility’s Interconnection Handbook or programs/contracts,

Aggregators acting for its DERs and DER Clients SHALL report the monitoring data in Table 2 and MAY include the data qualifiers in Table 3

G27.

For those situations where the DERs cannot provide Monitoring Data, the Aggregator acting for

its DERs and DER Clients SHALL not send the data.

G28.

Aggregators acting for its DERs and DER Clients SHALL have the capability to report the

Nameplate Ratings and Adjusted Settings information shown in Table 4.

G29.

Nameplate Ratings and Adjusted Settings SHOULD be reported once at start-up and whenever

there is a change in value.

G30.

Aggregators acting for its DERs and DER Clients SHALL have the capability to report the dynamic

Operational Status Information shown in Table 5.

G31.

Aggregators acting for its DERs and DER Clients SHALL have the capability to report the alarm

data shown in Table 6 as they occur.

G32.

All alarms and their “return to normal” messages SHALL include a date-time stamp along with

the alarm type.

IEEE 2030.5 Protocol Requirements

P1.

The specific version of the protocol implemented SHALL be IEEE 2030.5-2018.

P2.

Utility servers, Aggregators, and DER Clients SHALL support all CSIP required IEEE 2030.5 function

sets and resources in Table 7.

P3.

Unless otherwise specified in the utility’s Implementation Handbook, coordination of this time

and rates for updating this time SHALL conform to the requirements of IEEE 2030.5-2018.

P4.

Aggregators acting for its DERs and DER Clients SHALL support the EndDevice:DER resources in

Table 8 if the utility server makes them available.

P5.

Aggregators and DER Clients SHALL meet all IEEE 2030.5 mandatory requirements that are

described in the standard for each of these sections/functions unless otherwise specified in utility Interconnection Handbooks or programs/contracts.

P6.

HTTPS SHALL be used in all Direct and Aggregated communications scenarios.

P7.

Aggregators and DER Clients SHALL support the required IEEE 2030.5 security framework and

other security frameworks as required by the utility Interconnection Handbook or programs/contracts.

P8.

TLS version 1.2 SHALL be used for all HTTPS transactions.

P9.

DER Clients SHALL support the IEEE 2030.5 cipher suite.


P10.

Aggregators SHALL also support the TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suite or

other cipher suites as specified by the utility Interconnection Handbook or programs/contracts.

P11.

All utility servers, Aggregators, and DER Clients SHALL have a valid certificate.

P12.

A valid certificate SHALL be used in all IEEE 2030.5 TLS transactions.

P13.

Certificates for Aggregators and DER Clients SHALL only be provisioned upon completion of

Conformance Testing.

P14.

The GUID for both Aggregators and DERs SHALL be the IEEE 2030.5 Long Form Device Identifier

(LFDI) which is based on the 20-byte SHA-256 hash of the device’s certificate.

P15.

The certificates specified by each utility SHALL be used for authentication.

P16.

If authentication fails, the authenticator SHOULD issue a TLS Alert – Bad Certificate and close

the connection.

P17.

For Aggregators and DER Clients, the authorization list SHALL be based on the LFDI since the SFDI may not provide enough collision protection for a large population (e.g. 1 million) of

devices.

P18.

If the device is not on the authorization list, the utility server SHOULD return an HTTP error code

(e.g. 404 – Not Found) to terminate the transaction.

P19.

The utility SHALL establish the permissions for read, write, control, and other interactions,

based on agreements on which interactions are authorized between each DER and the utility.

P20.

When an Aggregator accesses the EndDeviceList, the utility server SHALL only present

EndDevices that are under the management of that Aggregator.

P21.

In the Direct DER Communications scenario, the GUID used to identify the DER Client SHALL be

the DER’s LFDI.

P22.

Implementers SHOULD refer to each utility’s Interconnection Handbook or programs/contracts

for more information needed to establish the LFDI.

P23.

Aggregators acting for its DERs and DER Clients SHALL track the DERProgram associated with

that group.

P24.

Aggregators acting for its DERs and DER Clients SHALL support up to 15 DERPrograms

simultaneously for each DER.

P25.

Aggregators acting for its DERs and DER Clients SHALL traverse all these links and lists to

discover all DERPrograms the DER is required to track.

P26.

For each DER EndDevice, the utility server SHALL use one FSA to point to a DERProgramList

containing all topology-based DERPrograms and MAY use additional FSAs to point to a

DERProgramList containing non-topology-based DERPrograms.

P27.

DER Clients SHALL be capable of supporting 15 FSAs.

P28.

For the CSIP Direct Communication scenario, the DER Client SHALL only receive function set assignments for a single energy connection point reflecting the aggregate capabilities of the

plant at its point of common coupling with the utility.

P29.

DER Clients SHALL use the IEEE 2030.5 mappings for the Grid DER Support Functions shown in

Table 9.

P30.

DERControls are IEEE 2030.5 events and SHALL conform to all the event rules in Section 12.1.3

of IEEE 2030.5-2018.

P31.

Aggregators SHALL subscribe to each DERProgramList assigned to its DERs to discover changes

in DERProgram:primacy.

P32.

Aggregators SHALL subscribe to the DERControlList of each DERProgram assigned to its DERs to

discover new controls or changes to existing controls.

P33.

Aggregators SHALL subscribe to the DefaultDERControl of each DERProgram assigned to its DERs

to discover changes to the default controls.


P34.

Unless otherwise specified in utility Interconnection Handbooks or programs/contracts to allow subscriptions, DER Clients SHALL poll to each DERProgram assigned to it to discover changes in

DERProgram:primacy.

P35.

Unless otherwise specified in utility Interconnection Handbooks or programs/contracts to allow subscriptions, DER Clients SHALL poll to the DERControlList of each DERProgram assigned to it to

discover new controls or changes to existing controls.

P36.

Unless otherwise specified in utility Interconnection Handbooks or programs/contracts to allow subscriptions, DER Clients SHALL poll to the DefaultDERControl of each DERProgram assigned to

it to discover changes to the default controls.

P37.

The utility MAY optionally specify a recommended polling rate for these resources using the

DERProgramList:pollRate resource.

P38.

If the polling rate is specified, DER Clients SHOULD poll at this rate.

P39.

Aggregators SHALL subscribe to the following lists:

EndDeviceList

FunctionSetAssignmentsList of each of the DERs under its management

DERProgramList of each of the DERs under its management

DERControlList of each of the DERs under its management

DefaultDERControls of each of the DERs under its management

P40.

Aggregators MAY subscribe to other lists and instances, such as EndDevice, DERProgram,

DERControl instances and others

P41.

Aggregators acting for its DERs and DER Clients SHALL use the IEEE 2030.5 Metering Mirror

function set to report metrology data.

P42.

Aggregators acting for its DERs and DER Clients SHOULD post readings based on the

MirrorUsagePoint:postRate resource.

P43.

Aggregators acting for its DERs and DER Clients SHALL be able to report the information shown

in Table 12.

P44.

Aggregators acting for its DERs and DER Client SHALL be able to report the dynamic status

information shown in Table 13.

P45.

DER Clients SHALL be able to report alarm data shown in 14.

P46.

The Aggregator SHOULD subscribe to the EndDeviceList to receive notifications for any additions

or changes to the list.

P47.

The Aggregator SHOULD subscribe to each EndDevice instance under its control to receive

notifications for any deletions of that instance.

P48.

For every inverter under its control, the Aggregator SHOULD subscribe to the list pointed to by

EndDevice: FunctionSetAssignmentsListLink to receive notifications for any changes in the

inverter’s group assignments.

P49.

For every inverter under its control, the Aggregator SHOULD subscribe to all of the

DERControlLists associated with its FSA groups and DERProgram assignments to receive notifications for any new or changed DERControl events.

P50.

For every inverter under its control, the Aggregator SHOULD subscribe to all of the

DERPrograms associated with its FSA groups to receive notifications for changes to the

DERProgram meta-data.


P51.

For every inverter under its control, the Aggregator SHOULD subscribe to all of the

DERProgramLists associated with its FSA groups to receive notifications for additions, deletions, or changes to the list.

P52.

Maintenance of subscriptions is described previously for the IEEE 2030.5 Specification. In particular:

• The Aggregator Client SHOULD renew its subscriptions periodically (e.g. every 24 hours) with the Utility Server.

• The Aggregator Client SHOULD fall back to polling on perceived communications errors.