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

‌6 CSIP IEEE 2030.5 Implementation‌

‌6.1 Utility Server Operation

This section describes the operation of the IEEE 2030.5 utility server. For the most part, the operations of the utility sever are the same whether communicating with an Aggregator or a DER. Where there are differences, sub-sections for Aggregator operation vs. DER operation will be provided.

‌6.1.1 Server and Resource Discovery

‌6.1.2 Registration

In IEEE 2030.5, registration is the process of creating an EndDevice instance for the device being registered. The utility server SHOULD only register authorized devices. The utility server SHOULD NOT allow access to critical resources to un-registered devices. The utility SHOULD return an HTTP error code (e.g. 404 – Not Found) for un-authorized accesses by un-registered devices.

‌6.1.3 Out-Of-Band DER Registration

In the out-of-band registration model, the utility server creates EndDevice instances corresponding to authorized devices at start-up, prior to any client device connecting to the server. The utility server receives a list of authorized devices via an out-of-band process. For example, a utility may generate this list internally, or receive it from an Aggregator. Each utility may have their own procedure for creating and updating this list, and these procedures are outside the scope of CSIP.

When an authorized DER queries the utility server’s EndDeviceList, the utility server SHOULD return an

EndDeviceList containing 1 entry – the EndDevice instance of the authorized device making the query.

When an unauthorized DER queries the utility server’s EndDeviceList, the utility server SHOULD return an HTTP error code (e.g. 404 – Not Found).

If a device tries to perform in-band registration by POSTing to the EndDeviceList, the server SHOULD return an HTTP error code (e.g. 403 – Forbidden).

‌6.1.4 In-Band DER Registration

In the in-band registration model, the utility server has a list of authorized devices, but does not create and EndDevice instance for the authorized devices at start-up. The utility server receives a list of authorized devices via an out-of-band process. For example, a utility may generate this list internally, or receive it from an Aggregator. Each utility may have their own procedure for creating and updating this list, and these procedures are outside the scope of CSIP.

When an authorized DER initially queries the utility server’s EndDeviceList, the utility server returns an empty EndDeviceList. The authorized DER tries to perform in-band registration by POSTing its EndDevice instance to the EndDeviceList. The utility server receives this POST and verifies the DER is in the authorized devices list. If it is, the utility server creates the EndDevice instance and returns an HTTP success code of 201 – Created, along with the location (i.e. URL) of the created EndDevice instance. Once created, any subsequent GETs of the EndDeviceList by this device returns an EndDeviceList containing a single entry – the EndDevice instance of the authorized device making the query.

If the device is not on the authorized list, the utility server SHOULD return an HTTP error code (e.g. 403 –

Forbidden).

The in-band registration model may be more convenient for installers that have a pool of authorized devices in its inventory and only needs to register them when they are installed at the customer site.

‌6.1.5 Aggregator Registration

An Aggregator is a special EndDevice to the utility server. The utility will likely use the out-of-band method to register an Aggregator though in-band registration is possible. As described in 6.1.3 and 6.1.4, the utility has a list of all the authorized devices managed by the Aggregator and has created EndDevice instances for those devices.

When the Aggregator starts up, it initially queries the server’s EndDeviceList. The server returns an EndDeviceList consisting of the Aggregator’s instance as well as the instances of all the authorized DERs under the Aggregator’s management. The Aggregator gets all the EndDevice instances to discover the group assignments of each EndDevice under its management.

‌6.1.6 Group Assignment of Inverters

The utility server is responsible for assigning an EndDevice to its groups. As a reminder, a group ultimately maps to a DERProgram. The DERProgram provides a reference to the controls and curves associated with a specific DER management program. The key components of the DERProgram are the primacy value (which sets the priority of this program) and the links to the DefaultDERControl, the DERControlList, and the DERCurveList. The utility server creates a DERProgram for each group in the system. Figure 5 shows an example DERProgram for the System A1 group of Figure 3.

‌Figure 5 - Example DERProgram

Once all the DERPrograms have been created, each EndDevice needs to be assigned to their appropriate groups. CSIP uses one FSA for topology groups and a second FSA for non-topology groups as described in section 5.2.3.1 to create the group assignments for each EndDevice. A DERProgramList is created for each of the FSAs, and group assignment simply consists of populating these lists with all the topology and non-topology DERPrograms (i.e. group assignments) for that EndDevice. An example of the DERProgramLists for Inverter-A of Figure 3 is shown in Figure 6.

‌Figure 6 - Example DERProgramLists for Inverter-A

The utility server then creates the FunctionSetAssignmentsList to link the DERProgramList with the appropriate EndDevice. An example FunctionSetAssignmentsList for Inverter-A shown in Figure 7. The EndDevice instance for the device will contain a link to this FunctionSetAssignmentsList.

‌Figure 7 - Example FunctionSetAssignmentsList for Inverter-A

‌6.1.7 EndDevice Creation

The utility server then creates the EndDevice instance that links to the appropriate FunctionSetAssignmentsList. An example EndDevice instance for Inverter-A is shown in Figure 8. Note that the FunctionSetAssignmentsListLink points to the list in Figure 7.

‌Figure 8 - Example EndDevice for Inverter-A

If the utility is using an Aggregator, an EndDevice instance for the Aggregator also needs to be created. There are a couple of differences between an Aggregator EndDevice instance and a DER EndDevice instance. First, the Aggregator uses IEEE 2030.5 subscription/notification, so it needs a SubscriptionListLink, and second, the Aggregator itself is not a DER, so it does not need a FunctionSetAssignmentsListLink. An example of an Aggregator EndDevice instance is shown in Figure 9.

‌Figure 9 - Example EndDevice for Aggregator

6.1.7.1 EndDevice Access

DERs or Aggregators get access to EndDevices through an EndDeviceListLink that is available via the

server’s DeviceCapability resource. The utility server should return a custom EndDeviceList for each device making the request. If the querying device is a DER, the server should return an EndDeviceList consisting of a single entry – the EndDevice instance of the requesting DER. An example of a DER EndDeviceList is shown in Figure 10.

‌Figure 10 - Example EndDeviceList for Inverter-A

If the querying device is an Aggregator, the server should return an EndDeviceList consisting of an entry for the Aggregator and entries for each DER under the Aggregator’s control. An example of an Aggregator EndDeviceList is shown in Figure 11.

‌Figure 11 - Example EndDeviceList for Aggregator

If the querying device is not authorized, the server should return an HTTP error code of (404 – Not Found) or (403 – Forbidden).

‌6.1.8 DER Control Management

The utility server sends controls to groups by creating a new DERControl and adding it to the DERControlList of the group’s DERProgram. CSIP uses three types of controls: immediate controls, default-only controls, and curve controls.

6.1.8.1 Immediate Controls

An immediate control is an IEEE 2030.5 DER event used to change the value of a control at a scheduled time for a scheduled duration. Table 9 shows the list of CSIP immediate controls. Immediate controls may have an optional default value that is applied when there are no events active. Figure 12 shows an example DERControlList containing a DERControl with the opModMaxLimW immediate control along with the opModVoltVar Curve control.

‌Figure 12 - Example Immediate and Curve DER Control

6.1.8.2 Default-Only Controls

A default-only control is a control that cannot be scheduled – it only exists in the DefaultDERControl of the DERProgram. This type of control is intended for settings that have an indefinite duration and are not expected to change often. Table 9 shows the list of CSIP default-only controls. Figure 13 shows an example DefaultDERControl with the setGradW and setSoftGradW default-only controls.

‌Figure 13 - Example of DefaultDERControl

6.1.8.3 Curve Controls

A curve control uses a series of (x, y) points to define the behavior of a dependent variable (y) based on the value of the independent variable (x). Table 9 shows the list of CSIP curve controls. A Curve control is an IEEE 2030.5 DER event which can be scheduled and can have an optional default curve that is applied when there are no events active. Figure 14 shows an example of DERCurveList containing two Volt-VAr curves. Figure 12 shows an example of DERControl scheduling Volt-VAr Curve 1.

‌Figure 14 - Example DER Curve List

‌6.2 Aggregator Operations

This informative section describes the typical operations of an Aggregator. Keep in mind that CSIP only addresses the utility to Aggregator communications. Communications between the Aggregator and its DERs is outside the scope of this document.

‌6.2.1 Host and Service Discovery

For this section, discovery is the process whereby the Aggregator obtains enough information to get the utility server’s DeviceCapability resource. There are many methods for the Aggregator to get this information, and the exact method to use is determined by the utility. Two methods are presented, but other methods could be used by mutual consent of the utility and Aggregator.

6.2.1.1 Out-Of-Band Discovery

In this model, the Aggregator is provisioned with all the information below by some out-of-band method (e.g. configuration file, webpage, user interface, etc.):

• The IP Address or DNS name of the utility server. If a DNS name is provided, the Aggregator performs a name resolution using unicast DNS.

• The HTTPS port to use. HTTP is not permitted for utility to Aggregator communications.

• The path to the DeviceCapability resource. This URL is the starting point for the Aggregator to

discover the utility server’s resources.

6.2.1.2 Unicast-DNS and DNS-SD

In this mode, the Aggregator is provisioned with the DNS name of the utility server. The Aggregator performs name resolution using unicast DNS to obtain the server’s IP address. The Aggregator uses DNS- based service discovery (DNS-SD) to obtain the port, scheme (HTTP or HTTPS), and the path to the DeviceCapability resource. Refer to the IEEE 2030.5 specification for more details pertaining to DNS-SD.

‌6.2.2 Security, Authentication, and Authorization

Once the Aggregator has determined the location (URL) of the utility server’s DeviceCapability resource, the Aggregator performs an HTTP GET of this resource. This action initiates a TLS handshake to establish a secure connection. Certificates are exchanged between the utility server and the Aggregator during

the handshake. The utility server authenticates the Aggregator’s certificate and verifies whether it is

authorized.

Once the utility server authenticates and authorizes the Aggregator, it returns the contents of the DCAP resource with an HTTP response code of 200 – OK. If the Aggregator fails to authenticate or is not authorized, the utility server can abort the TLS connection by sending a TLS Alert message, or it can complete the TLS connection but return an HTTP response code of 403 – Forbidden.

‌6.2.3 Getting Server Resources

Once a secure connection has been established, the Aggregator can get resources from the utility server.

6.2.3.1 DeviceCapability

The DeviceCapability resource is the starting point for discovering resources on the server. It provides links to the entry point of function sets supported by the server. An example DeviceCapability resource is shown in Figure 15.

‌Figure 15 - Example Aggregator DeviceCapability

6.2.3.2 EndDeviceList

Once the Aggregator obtains DeviceCapability, it then gets the EndDeviceListLink to get its EndDevice instance along with the EndDevice instances of all the DERs under its control. An example of this EndDeviceList was shown in Figure 11. An example of the Aggregator instance was shown in Figure 9, and an example of a DER instance was shown in Figure 8.

6.2.3.3 Subscriptions

The Aggregator instance contains the SubscriptionListLink. The Aggregator posts to this link to create subscriptions to resources for which it wants to receive notifications. The Aggregator subscribes to the following resources:

• EndDeviceList – to detect additions/deletions and enabling/disabling of DERs

• DERProgramList – to detect changes to the group assignments of each DER and to detect changes in the priority of each DERProgram

• DERControlList – to detect the creation of a DERControl and changes to its status

• DefaultDERControl – to detect changes in the default controls of each DERProgram

The Aggregator may subscribe to other resources if allowed by the server. Figure 16 shows and example subscription to the EndDeviceList resource requesting a list limit of up to 1 entries.

‌Figure 16 - Example EndDeviceList Subscription

The Aggregator acts on behalf of all the DERs it manages. It is highly likely these DERs belong to many of the same groups, and there are significant overlaps in the resources the Aggregator is monitoring on behalf of the DERs. The Aggregator needs to keep track of these overlaps so that it only subscribes to a shared resource once.

6.2.3.4 Notifications

When a subscribed resource changes, the utility server posts a Notification to the Aggregator. For list resources, the Notification payload may contain entries from the list, depending on the limit setting of the requested by the Aggregator and the policy of the server. The Aggregator may need to perform additional list queries to get all changes to the list. Refer to the IEEE 2030.5 specification for details about subscription/notification behavior. An example of a Notification to an EndDeviceList subscription is shown in Figure 17.

‌Figure 17 - Example EndDeviceList Notification

‌6.2.4 Acting on DER Controls

Once the Aggregator has retrieved and/or subscribed to the necessary DER resources, it waits for Notifications of new DERControl events. The new DERControl may be sent with the Notification. Otherwise, the Aggregator uses the Notification to trigger a GET of the DERControlList containing the new DERControl. At the start time of the event, the Aggregator activates the control for all the targeted DERs, and at the end of the event, the Aggregator de-activates the control returning the control to its default value, if a default was specified. How the Aggregator activates/de-activates the control for all the targeted DERs is outside the scope of CSIP.

If Responses are enabled for the DERControl, the Aggregator must post the appropriate Responses on behalf of each targeted DER.

‌6.2.5 Reporting DER Data

6.2.5.1 Reporting Monitor Data

For every DER under its control, the Aggregator reports monitor data described in 5.2.5.1. For each DER, the Aggregator creates a MirrorUsagePoint (MUP) instance for the DER by posting to the utility server’s MirrorUsagePointListLink specified in the DeviceCapability resource. The location of this newly created instance is returned in the server response (e.g. /mup/1). An example of the contents of a MUP post for Inverter A is shown in Figure 18. This MUP post contains the definition of a MirrorMeterReading for reporting a Real Power set. Every 24 hours, the Aggregator posts a new Real Power reading set for each DER. An example of this reading set post is shown in Figure 19. The Aggregator makes similar posts for all type of metrology specified in Table 2.

‌Figure 18 - Example MirrorUsagePoint POST

‌Figure 19 - Example MirrorMeterReading POST

6.2.5.2 Reporting Status Information

For every DER under its control, the Aggregator reports status data described in 5.2.5.2. Figure 20 shows an example DERCapability post, Figure 21Figure 21 shows an example DERSettings post, and Figure 22 shows an example of a DERStatus post. For DERCapability and DERSettings, the Aggregator posts these resources at device start-up and on any changes. For DERStatus, the Aggregator posts at the rate specified in DERList:pollRate.

‌Figure 20 - Example DERCapability POST

‌Figure 21 - Example DERSettings POST

‌Figure 22 - Example DERStatus POST

6.2.5.3 Reporting Alarms

For every DER under its control, the Aggregator reports alarm data using the LogEvent function set described in 5.2.5.3 as they occur. Figure 23 shows an example LogEvent post for an over-current fault condition.

‌6.3 DER Device Operations‌

Figure 23 – Example LogEvent POST

This informative section describes the typical operations of a DER Client when communicating directly with the utility server.

‌6.3.1 Host and Service Discovery

For this section, discovery is the process whereby the DER Client obtains enough information to get the

utility server’s DeviceCapability resource. There are many methods for the DER Client to get this

information, and the exact method to use is determined by the utility. Two methods are presented, but other methods could be used by mutual consent of the utility and DER.

6.3.1.1 Out-Of-Band Discovery

In this model, the DER Client is provisioned with all the information below by some out-of-band method (e.g. configuration file, webpage, user interface, …):

• The IP Address or DNS name of the utility server. If a DNS name is provided, the DER performs a name resolution using unicast DNS.

• The HTTPS port to use. HTTP is not permitted for utility to DER communications.

• The path to the DeviceCapability resource. This URL is the starting point for the DER to discover

the utility server’s resources.

6.3.1.2 Unicast-DNS and DNS-SD

In this mode, the DER Client is provisioned with the DNS name of the utility server. The DER Client performs name resolution using unicast DNS to obtain the server’s IP address. The DER Client uses DNS- based service discovery (DNS-SD) to obtain the port, scheme (HTTP or HTTPS), and the path to the DeviceCapability resource. Refer to the IEEE 2030.5 specification for more details pertaining to DNS-SD.

‌6.3.2 Security, Authentication, and Authorization

Once the DER Client has determined the location (URL) of the utility server’s DeviceCapability resource, the DER Client performs an HTTP GET of this resource. This action initiates a TLS handshake to establish a secure connection. Certificates are exchanged between the utility server and the DER Client during the handshake. The utility server authenticates the DER Client’s certificate and verifies whether it is authorized.

Once the utility server authenticates and authorizes the DER Client, it returns the contents of the DeviceCapability resource with an HTTP response code of 200 – OK. If the DER fails to authenticate or is not authorized, the utility server can abort the TLS connection by sending a TLS Alert message, or it can complete the TLS connection but return an HTTP response code of 403 – Forbidden.

‌6.3.3 Getting Server Resources

Once a secure connection has been established, the DER Client can get resources from the utility server.

6.3.3.1 DeviceCapability

The DeviceCapability resource is the starting point for discovering resources on the server. It provides links to the entry point of function sets supported by the server. An example DeviceCapability resource is shown in Figure 24. It is similar to the Aggregator version shown in Figure 15 except the length of the EndDeviceList is 1.

‌Figure 24 - Example DER Client DeviceCapability

6.3.3.2 EndDeviceList

Once the DER Client obtains DeviceCapability, it then gets the EndDeviceListLink to get its EndDevice

instance. An example of this EndDeviceList was shown in Figure 10Figure 11.

6.3.3.3 Polling for Resources

Once the DER Client gets its EndDevice instance, it finds its group assignments by following the FunctionSetAssignmentsListLink. From there, the DER finds the DERProgramListLink, the DERProgramList, all its assigned DERPrograms, DERControlLists, DefaultDERControls, DERCurveLists, etc. The DER Client periodically polls these resources at a rate specified by the DERProgramList:pollRate setting.

‌6.3.4 Acting on DER Controls

Once the DER Client has retrieved the necessary DER resources, it waits for new DERControl events. At the start time of the event, the DER Client activates the control, and at the end of the event, the DER Client de-activates the control returning the control to its default value, if a default was specified.

If Responses are enabled for the DERControl, the DER Client posts the appropriate Responses.

‌6.3.5 Reporting DER Data

6.3.5.1 Reporting Monitor Data

The DER Client reports monitor data described in 5.2.5.1. The DER Client creates a MirrorUsagePoint (MUP) instance by posting to the utility server’s MirrorUsagePointListLink specified in the DeviceCapability resource. The location of this newly created instance is returned in the server response (e.g. /mup/1). An example of the contents of a MUP post for Inverter A is shown in Figure 19. This MUP post contains the definition of a MirrorMeterReading for reporting a Real Power set. Every 24 hours, the DER posts a new Real Power reading set. An example of this reading set post is shown in Figure 19. The DER makes similar posts for all type of metrology specified in Table 10.

6.3.5.2 Reporting Status Information

The DER Client reports status data described in 5.2.5.2. Figure 20 shows an example DERCapability post, Figure 21 shows an example DERSettings post, and Figure 22 shows an example of a DERStatus post. For DERCapability and DERSettings, the DER posts these resources at device start-up and on any changes.

For DERStatus, the DER posts at the rate specified in DERList:pollRate.

6.3.5.3 Reporting Alarms

The DER reports alarm data using the LogEvent function set described in 5.2.5.3 as they occur. Figure 23 shows an example LogEvent post for an over-voltage fault condition.

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