IEEE Std 2030.5-2018: 智能能源管理应用协议详解

版权申诉

5星 · 超过95%的资源 61 浏览量更新于2024-07-20 2 收藏 5.6MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"IEEE Std 2030.5-2018 是一份智能能源配置文件应用协议的标准文档，由IEEE电力线通信委员会赞助，旨在定义一套应用协议，以支持公用事业对终端用户能源环境的管理。该协议涵盖了需求响应、负荷控制、每日定价、分布式发电以及电动汽车管理等多个领域，利用TCP/IP的传输层和互联网层功能。它基于RESTful体系结构，遵循IETF协议如HTTP，并与多个现有的国际标准，如IEC 61968和IEC 61850相兼容。文档共361页，详细阐述了智能能源管理的相关技术规范和应用接口。" 此文档是IEEE在2018年修订的版本，更新了2013年的标准IEEE Std 2030.5-2013。它提供了一个标准化框架，用于不同物理层协议（如IEEE 802.15.4、IEEE 802.11、IEEE 1901和IEEE 1901.2等）间的智能能源交互。虽然主要关注应用层，但标准中也会提及与应用协议直接相关的较低层协议交互。关键知识点： 1. **智能能源管理**：该标准旨在实现更智能、更高效的能源管理系统，通过自动化和远程控制技术，提高能源利用效率，减少能耗。 2. **应用协议**：定义了一套应用层协议，这是智能能源系统中设备间通信的基础，允许数据交换和服务互动，如需求响应和负荷控制。 3. **TCP/IP**：TCP/IP协议栈在智能能源应用中起着基础性作用，提供了网络传输和互联网连接的必要功能。 4. **RESTful体系结构**：遵循REST原则，意味着协议设计简洁，易于理解和实现，且具有良好的可扩展性，适合大规模分布式系统的交互。 5. **需求响应**：指能源消费者根据电网需求调整自己的用电行为，以帮助平衡供需，降低高峰时段的电力需求。 6. **负荷控制**：通过对终端用户的电力使用进行计划和调度，以优化电网运行，避免过载。 7. **每日定价**：一种电价策略，根据一天中的时间调整价格，鼓励消费者在非高峰时段用电，以减轻电网压力。 8. **分布式发电**：来自太阳能、风能等可再生能源的小型发电设施，可以并入电网，提供本地化电力供应。 9. **电动汽车管理**：考虑到电动汽车的充电需求，该协议考虑如何协调充电行为，以减轻电网负荷。 10. **兼容性**：与IEC 61968和IEC 61850等国际标准兼容，确保不同系统之间的互操作性。 11. **物理层协议**：虽然不详尽讨论，但标准中提到了各种可能的物理层协议，它们是智能能源通信的基础，负责数据的物理传输。这份标准文档对于理解和实施智能能源解决方案的工程师、研究人员以及能源行业从业者来说，是一份重要的参考资料。它为构建和集成智能能源系统提供了标准化的方法和指南。

资源详情

资源推荐

IEEE Std 2030.5-2018

IEEE Standard for Smart Energy Profile Application Protocol

device certificate: A digital certificate installed within a device that binds the device identity to the device.

Device certificates are exchanged by network access control and application protocols to authenticate

devices as genuine IEEE 2030.5 and further to prove specific device identity.

energy services interface (ESI): A device, with multiple network interfaces, which is a member of both

the home smart energy network and a service provider’s private network. This is the primary mechanism

for the service provider to contribute data and directives into the smart energy network and to receive

responses from smart energy devices.

fingerprint: This is the result of summarizing a certificate with a secure hash function. The fingerprint is

generally expressed as a hex string. It is used to confirm the integrity of a certificate obtained over an

untrusted channel.

function set: A logical grouping of resources that cooperate to implement IEEE 2030.5 features (e.g.,

metering, demand response, and load control).

Function Set Assignments: A logical addressing mechanism in IEEE Std 2030.5 that allows devices to be

directed to use specific resources (e.g., to facilitate a device’s participation in a program). Please see 8.6 for

details.

function set instance: A single, top-level, instance of a function set (e.g., a single UsagePoint for the

Metering function set, a single DemandResponseProgram for the Demand Response and Load Control

function set).

host: This is the representation of a device in its application context. Typically represented by an Internet

Protocol (IP) address or domain name.

intermediate CA: A certificate authority (CA) below the root CA that issues certificates to subordinate

CAs.

issuing CA: A certificate authority (CA) that issues certificates to devices or code-signers.

manufacturer’s CA (MCA): An intermediate certificate authority (CA) operated by a specific

manufacturer for the purpose of issuing manufacturing issuing CAs for that manufacturer.

manufacturing issuing CA (MICA): An issuing certificate authority (CA) that issues certificates to

devices during the manufacturing process.

manufacturing public key infastructure (PKI): The set of certificate authorities (CAs) that issue

certificates to devices during the manufacturing process. The set includes the Smart Energy Root CA,

Manufacturer’s CAs, and Manufacturing Issuing CAs.

master resource identifier (mRID): An mRID is the global identifier attribute of an object. For further

definition and formatting, see the schema (IEEE Std 2030.5 supplemental material).

node: This is the representation of a device in its network context, typically represented as an Internet

Protocol (IP) address.

object identifier (OID): An OID consists of a node in a hierarchically-assigned namespace, formally

defined using ITU-T’s ASN.1 standard (ITU-T Recommendation X.680).

privacy-enhanced electronic mail (PEM) format certificate: An X.509 certificate that has been Base64

encoded and wrapped in "-----BEGIN CERTIFICATE-----", "-----END CERTIFICATE-----" sentinels for

transport as a text file or block.

IEEE Std 2030.5-2018

IEEE Standard for Smart Energy Profile Application Protocol

public key infrastructure (PKI): A set of hardware, software, people, policies, and procedures needed to

create, manage, distribute, use, store, and revoke digital certificates.

registered: The state of a device with regards to a particular server wherein an EndDevice record for the

device has been populated on the server and that record contains a valid registration record. These records

are typically populated with device information transmitted out-of-band to the server’s owner.

resource: Uniform resource identifier (URI) addressable object that is manipulated via the RESTful

uniform interface.

resource discovery: The process whereby clients identify resources being served on the network. Clients

issue a request to all devices on the network requesting resource(s) of interest. Servers hosting the

requested resource(s) respond with information necessary to access the server and its resource(s).

root CA: A certificate authority (CA) whose certificate or public key is a trust anchor for any other

certificates in a chain of trust.

root certificate: The root certificate authority’s self-signed certificate. Generally also a trust anchor.

self-signed certificate: A certificate whose issuer and subject are identical, and whose public key verifies

its signature.

server: The device or host that holds a resource and exposes representations of that resource.

Smart Energy Root CA (SERCA): The top-level certificate authority (CA) for the IEEE 2030.5

manufacturing public key infastructure (PKI).

trust anchor: The root of trust for a certificate chain. This is an authoritative entity represented by a public

key and associated data and is generally provided in the IEEE 2030.5 hierarchy in the form of a self-signed

certificate.

trusted root store: An integrity-protected location for storing root certificates.

3.2 Acronyms and abbreviations

This subclause provides a list of acronyms and abbreviations introduced in this document.

ACL access control list

CA certificate authority

CRL certificate revocation list

DER distributed energy resource

DNS Domain Name System

DNS-SD DNS-based Service Discovery

DRLC demand response and load control

ECDSA Elliptic Curve Digital Signature Algorithm

IEEE Std 2030.5-2018

IEEE Standard for Smart Energy Profile Application Protocol

4. Design pattern

4.1 Protocol flexibility

IEEE Std 2030.5 is designed to implement a REST architecture. It is built around the core actions of GET,

HEAD, PUT, POST, and DELETE (as used in (Fielding [B3]), with the addition of a lightweight

subscription mechanism as discussed in 8.7. Any application protocol that can implement a RESTful

command set could likely be used with IEEE Std 2030.5, but Hypertext Transfer Protocol (HTTP) is a

required baseline for interoperable IEEE 2030.5 implementations. HTTP utilizes Transmission Control

Protocol (TCP) as its transport protocol. As a result, TCP manages the session providing delivery assurance

and windowing.

IEEE 2030.5 servers and clients SHALL be compliant with IETF RFC 7230, IETF RFC 7231, IETF RFC

7232, IETF RFC 7233, IETF RFC 7234, and IETF RFC 7235.

4.2 General rules/best practices

This standard shall not make distinctions between servers, clients, or devices when defining interfaces and

uniform resource identifiers (URIs). The goal is to avoid having a resource that has one behavior on a

server and a different behavior on a client or different type of server. The distinction between the server and

client role depends on whether a device exposes a resource (server) or interacts with the resource (client).

The default mechanism for obtaining a resource representation is a pull mechanism, implemented with

GET. A client requests and retrieves data from a server or creates, modifies, or deletes data on a server.

The default polling rate for a given function set is specified at the top-level resource of that function set in

the pollRate attribute.

The use of a subscription mechanism for retrieving a resource representation is also optionally supported,

where convenient and appropriate. Resources that support subscription are denoted by their subscribable

attribute.

Objects have a defined granularity and whole objects (not partial objects) are to be updated with the

granularity defined in the schema.

Clients that expect to have intermittent connections to the network (e.g., battery-powered sleepy devices,

mobile devices, etc.) use a pull mechanism as their default behavior for resource retrieval, as a

Subscription/Notification mechanism may not be reliable. It should be noted that clients that expect to have

intermittent connections to the network may still POST, PUT, and DELETE resources, provided they have

the appropriate security permissions.

The TCP ports used for HTTP or Hypertext Transfer Protocol Secure (HTTPS) SHALL be specified in the

xmDNS service advertisement for the service.

Content SHALL be transferred with either one of the content types: “application/sep+xml” or

“application/sep-exi.”

Devices do not assume the use of the URIs and their structures given throughout this standard. All

resources are self-describing as it is acknowledged that URIs, schemas, and resources might change in the

future. All resources SHALL contain links to their subordinate resources to support flexibility in URIs and

future extensibility. Thus, to allow for extensibility and granularity, all objects are described in schemas

and referenced via URIs. The URIs presented throughout this standard are recommendations. Thus, clients

IEEE Std 2030.5-2018

IEEE Standard for Smart Energy Profile Application Protocol

do not assume that URIs for resources are fixed on all servers or even on a given server (over time), but

rather retrieve the appropriate URIs through resource discovery and links within resources. For network

efficiency, devices MAY assume URIs are fixed on a particular server over time. If a URI returns an

unexpected result, the client SHOULD execute resource discovery to determine the new URI value.

Version information should not be presented in the URI unless that version information is inherent to the

name of that resource. If necessary and for reasons of extensibility, version information is provided within

the associated resources and/or schemas.

All values in XML and EXI SHOULD be represented as compactly as possible. Decimal values SHOULD

be represented without leading zeros. Hexadecimal values SHALL be represented with one leading zero, if

needed, to ensure an even number of digits.

4.3 WADL

The IEEE 2030.5 RESTful interface is defined using the Web Application Description Language (WADL)

(IEEE Std 2030.5 supplemental material).

IEEE 2030.5 devices SHALL conform to the interface specifications contained in the WADL as follows:

a) Devices SHALL conform to the WADL specification as per W3C WADL.

b) Devices SHALL conform to the WADL definition in the supplemental material of IEEE Std 2030.5.

By implication, all resource representations SHALL validate per the schema (IEEE Std 2030.5

supplemental material) within the standardized IEEE 2030.5 XML namespace

(

urn:ieee:std:2030.5:ns).

c) Compliance (MODE) designations are interpreted as follows:

1) Mandatory ("M"): Devices MUST implement and conform.

2) Optional ("O"): Devices MAY implement, and if implemented, MUST conform.

3) Discouraged ("D"): Devices SHOULD NOT implement, but if implemented, MUST conform.

4) Error ("E"): Devices MUST return one of the specified response status codes (e.g., 400 Bad

Request or 405 – Method Not Allowed).

4.4 Schema

Resources located at URIs returned in the href attribute of "Link" specializations (e.g., EndDeviceListLink,

SelfDeviceLink) SHALL conform to the schema definition for that object, which is the tag name with the

“Link” suffix removed. For example, the resource at SelfDeviceLink href follows the definition for the

SelfDevice resource.

If a client PUTs or POSTs a resource to a server containing attributes or elements that instead are to be

populated by the server (e.g., href), the server SHALL return an HTTP 400 error.

If a function set is not implemented, Link elements to resources in that function set SHALL NOT be

included.

剩余360页未读，继续阅读

johnho888

粉丝: 5
资源: 39

IEEE Std 2030.5-2018: 智能能源管理应用协议详解

IEEE智能电网规划2030系列——controls部分

最新完整版标准 ISO 16750-1 2018.pdf

ISO_16750-1：2018_Part 1：General .pdf

ieee std 2030.5-2018

ieee std 802.3-2018 pdf 下载

ieee std 802.3 -2018

ieee std 802.3 -2018中文版

ieee2030.8-2018

ieee std 802.3-2022下载

ieee std 1003.1-2017

ieee std 802.3bt-2018

ieee std 802.11-2020下载

ieee std 802.11 -2016

ieee std 1149.1-2013

jtag 标准 ieee std 1149.1-2013

ieee std 802.3cd-2018

ieee 1901.1-2018 下载

ieee 802.3-2018中文

ieee standard for ethernet 802.3-2018.pdf

ieee std. 1394b - 2002 ieee standard for a high-performance

最新资源