IEC 62056-51: 电度表数据交换应用层协议

62056

3星 · 超过75%的资源需积分: 10 114 浏览量更新于2024-07-27 收藏 292KB PDF 举报

"IEC 62056-51是关于电度表数据交换标准的一部分，专注于应用层协议的定义，旨在促进电表读数、费率管理和负载控制的数据交换。这一标准由国际电工委员会（IEC）于1998年11月首次发布，编号为CEI/IEC62056-51:1998。自1997年1月1日起，IEC的所有出版物都从60000号开始编号。" IEC 62056系列标准，也称为“Data exchange for meter reading, tariff and load control”，是电力行业的一个关键规范，它定义了智能电表与系统之间通信的统一方法。第51部分专门涵盖了应用层协议，这是七层OSI模型中的最高层，负责处理特定应用的数据传输和解析。在IEC 62056-51中，主要包含以下知识点： 1. **应用层协议**：这部分定义了用于电表读数、费率设置和负载控制的通信协议。这些协议确保不同制造商的设备可以相互通信，实现数据的标准化交换。 2. **电度表数据交换**：标准规定了如何收集和传输电表的读数，这包括瞬时功率读数、累计用电量以及可能的故障或异常信息。 3. **费率管理**：协议支持动态费率设定，允许电网运营商根据时间和需求调整电价，促进能源的高效使用。 4. **负载控制**：通过应用层协议，可以远程控制负载，例如在高峰时段限制某些设备的功率，以平衡电网负载。 5. **版本和修订**：IEC出版物会定期更新和修订，以反映技术的进步。例如，1.0版是基础版本，1.1版包含了第一份修正案，1.2版则包含了第1和第2号修正案的内容。 6. **有效性和确认**：IEC的出版物会不断更新以保持技术的最新状态。这意味着IEC 62056-51可能会经历多次修订，以适应新的技术需求和市场变化。 7. **兼容性与互操作性**：IEC 62056-51确保不同供应商的设备能够无缝对接，提高了整个电力系统的兼容性和互操作性，有利于大规模部署智能电网。 8. **实施与应用**：在实际应用中，该标准通常被电力公司、设备制造商和软件开发商用于开发和集成电表系统，以提高服务质量和效率。 IEC 62056-51是电力行业的一个重要规范，它的存在促进了智能电网的发展，使得数据交换更加高效和可靠，有助于实现更智能、更环保的能源管理。

62056-51 © IEC:1998 – 11 –

The terms Client and Server have the same meanings as in the DLMS model (see IEC 61334-4-41).

The Server is the system that acts as a VDE (see IEC 61334-4-41) for the submission of all

special service requests. The Client is the system that uses the Server for a specific purpose

by means of one or more service requests.

The situation involving a Caller Client and a Called Server is undoubtedly the most frequent

case, but a communication based on a Caller Server and a Called Client is also possible, in

particular to report the occurrence of an urgent alarm.

2.2 Sub-layers and protocols

The Application layer model described in this technical report uses a breakdown into three sub-

layers: Transport, Application and DLMS. Each of these sub-layers is the subject of a protocol

whose name is given in the table 1.

Table 1 – Sub-layers and protocols

Sub-layers Protocols

DLMS DLMS+

Application Application+

Transport Transport+

The Transport and Application sub-layers set up a homogeneous package called LLAC (Logical

Link Access Control).

The DLMS+ protocol of the DLMS sub-layer is described in IEC 61334-4-41.

2.3 Specification language

In this technical report, the protocol of each sub-layer is described by state transitions

represented in the form of tables. The syntax used in making up these tables is defined by a

specification language described in annex A.

In the event of a difference in interpretation between part of the text and a state transition

table, the table is always taken as the reference.

3 Transport sub-layer

3.1 Transport+ protocol

The Transport+ protocol of the Transport sub-layer is designed to support the multiplexing of

transport connections. It is strictly identical for the Caller and for the Called party (completely

symmetrical behaviour).

3.2 General information

The Transport sub-layer is the first one to handle direct connections between the systems at

the ends of the links. All the connections set up at this level and those at higher levels can be

considered as end-to-end links. This end-to-end notion indicates that the transport entities offer

services which are completely independent of the physical networks.

– 12 – 62056-51 © CEI:1998

Les propriétés les plus importantes de la sous-couche Transport sont le transport de bout en

bout (déjà mentionné), la transparence (toute configuration binaire doit être acceptée par le

protocole de transport pour être délivrée sans modification, quel que soit son format ou sa

taille) et la sélection d'une qualité de service. La notion de qualité de service n'est mentionnée

ici que pour mémoire, dans la mesure où le protocole Transport+ est orienté sans connexion.

La sous-couche Transport est chargée de prendre les messages provenant de la sous-couche

Application. Etant donné que ces messages ont une taille dictée par l'application, la sous-

couche Transport doit les segmenter en paquets (appelés TPDU: unités de données du

protocole de transport) et les transmettre à la sous-couche Transport en correspondance.

Réciproquement, elle doit recevoir les paquets provenant de la sous-couche Transport en

correspondance puis assembler ceux-ci afin de les restituer sous forme de messages

cohérents à la sous-couche Application.

Le protocole Transport+ doit pouvoir transmettre en parallèle des données dans les deux sens

Appelant-Appelé et Appelé-Appelant. En outre, la solution du multiplexage des connexions de

transport sur le même circuit virtuel assure que plusieurs associations d'application peuvent

coexister dans une même communication.

Quelle que soit leur origine, les TPDU sont émises en utilisant les services de la couche

Liaison. Bien entendu, cette dernière ignore tout du multiplexage mis en oeuvre au niveau

supérieur.

3.3 Classes de protocole de transport

L'ISO propose différents types de services de réseaux en fonction des erreurs résiduelles dans

les transmissions aux niveaux inférieurs. Deux sortes d'erreurs sont identifiées: les erreurs

signalées (par exemple déconnexion autoritaire avec indication d'erreur) et les erreurs non

signalées (erreurs de transmission non détectées et non corrigées). Sur cette base, trois types

de réseaux existent et sont indiqués au tableau 2.

Tableau 2 – Types de services de réseaux en fonction des erreurs résiduelles

Type Définition

A Taux acceptable d'erreurs résiduelles (signalées et non

signalées)

B Taux acceptable d'erreurs non signalées

Taux inacceptable d'erreurs signalées

C Taux inacceptable d'erreurs des deux types

Le protocole Transport+ s'inspire de la classe 2 de l’ISO qui suppose un réseau de type A, et

qui est caractérisée par des fonctions de segmentation et d'assemblage avec multiplexage,

mais sans reprise sur erreur ni contrôle de flux.

3.4 Services et primitives de service de transport

L'utilisateur du protocole Transport+ dispose des services et primitives de service donnés au

tableau 3.

Tableau 3 – Services et primitives de service de transport

Service Primitive

T_DATA T_DATA.req(STSAP, DTSAP, Pr, TSDU)

T_DATA.ind(STSAP, DTSAP, TSDU)

T_ABORT T_ABORT.req(Strong)

T_ABORT.ind(ErrorNb)

62056-51 © IEC:1998 – 13 –

The most important properties of the Transport sub-layer are end-to-end transport (mentioned

above), transparency (any binary configuration must be accepted by the transport protocol and

delivered without modification, whatever its format or size) and selection of a quality of service.

The notion of quality of service is mentioned here for information only, as the Transport+

protocol is oriented without connection.

The Transport sub-layer accepts the messages from the Application sub-layer. As the size of

these messages is dictated by the application, the Transport sub-layer must segment them into

packets (called TPDUs: transport protocol data units) and transmit them to the correspondent

Transport sub-layer. Reciprocally, it must receive the packets from the correspondent

Transport sub-layer and assemble them into coherent messages for the Application sub-layer.

The Transport+ protocol must be able to transmit data in parallel in both directions, Caller-

Called and Called-Caller. Moreover, the multiplexing of transport connections on the same

virtual circuit means that several application associations can coexist in a given communication.

Whatever their origin, the TPDUs are transmitted using the services of the Data Link layer. Of

course, this sub-layer is not aware of the multiplexing implemented at the higher level.

3.3 Transport protocol classes

The ISO proposes different types of network services depending on the residual errors in the

transmissions at the lower levels. Two sorts of error are identified: the reported errors (for

example forced disconnection with error indication) and the unreported errors (undetected and

uncorrected transmission errors). On this basis, there are three types of network, summarized

in table 2.

Table 2 – Types of network services depending on residual errors

Type Definition

A Acceptable residual error rate (reported and unreported)

B Acceptable rate of unreported errors

Unacceptable rate of reported errors

C Unacceptable rate of both types of errors

The Transport+ protocol is derived from ISO class 2 which supposes a type A network, and

which is characterized by segmenting and assembly functions with multiplexing, but without

resumption after error or flow control.

3.4 Transport services and service primitives

Table 3 services and service primitives are available to users of the Transport+ protocol.

Table 3 – Transport services and service primitives

Service Primitive

T_DATA T_DATA.req(STSAP, DTSAP, Pr, TSDU)

T_DATA.ind(STSAP, DTSAP, TSDU)

T_ABORT T_ABORT.req(Strong)

T_ABORT.ind(ErrorNb)

Le rôle attribué à chaque primitive est le suivant:

– T_DATA.req(STSAP, DTSAP, Pr, TSDU) permet à la sous-couche Application de demander

à la sous-couche Transport le transfert avec la priorité Pr

d'un message TSDU depuis

une adresse de transport source STSAP vers une adresse de transport destination DTSAP

ou bien depuis une adresse de transport destination DTSAP vers une adresse de transport

source STSAP;

– T_DATA.ind(STSAP, DTSAP, TSDU) permet à la sous-couche Transport d'informer la

sous-couche Application de l'arrivée d'un message TSDU depuis une adresse de transport

source STSAP vers une adresse de transport destination DTSAP ou bien depuis une

adresse de transport destination DTSAP vers une adresse de transport source STSAP;

– T_ABORT.req(Strong) permet à la sous-couche Application de demander à la sous-couche

Transport de mettre fin à son activité avec la priorité Strong

;

– T_ABORT.ind(ErrorNb) permet à la sous-couche Transport d'informer la sous-couche

Application de l'occurrence d'une erreur fatale repérée par le numéro ErrorNb.

3.5 Description des unités de données du protocole transport (TPDU)

Les messages échangés entre entités de transport sont acheminés par segments dans des

TPDU qui contiennent chacune un nombre entier d'octets.

Dans le protocole Transport+, il n'y a qu'un seul type de TPDU défini par les cinq champs

suivants:

– TPDUType (DT+) : 3 bits

– End : 1 bit

– STSAP : 2 bits

– DTSAP : 10 bits

– Packet : 0 octet à MaxPktSize octets

bits

bit

bits

0 octet à MaxPktSize

octets

DT+ End STSAP DTSAP Packet

Figure 1 – Structure d'un TPDU

Le champ DT+ est toujours codé "101"B.

Lorsqu'il est positionné à 1, le bit du champ End indique que l'unité de données

correspondante est la dernière d'un message segmenté.

Le champ STSAP référence l'adresse de transport source et le champ DTSAP correspond à

l'adresse de transport destination. Par convention, la valeur "0000000000"B est réservée au

DTSAP du Serveur DLMS d'administration des protocoles de communication.

Enfin, le champ Packet correspond au segment de données courant.

–––––––––

Le niveau de priorité Pr permet de différencier le traitement des services urgents tels que InformationReport

(niveau Pr=1) de celui des autres services DLMS (niveau Pr=0).

Le paramètre Strong permet de différencier le traitement des erreurs fatales (Strong=1) de celui des autres

demandes de déconnexion physique (Strong=0) initialisées par la sous-couche Application.

剩余77页未读，继续阅读

sonyzb

粉丝: 0
资源: 10

IEC 62056-51: 电度表数据交换应用层协议

IEC 62056-51-1998

IEC 62056中文全套

IEC 62056 中文版

IEC 62056 国际标准

IEC62056 全套规约

IEC62056 全套 中文Word格式

全套IEC 62056规约，pdf格式

仪表数据的国际通讯规约IEC62056

IEC 62056协议全套(带中文版)

电力行业62056标准全套.rar

最新资源

IEC62056 全套中文Word格式