SIST EN 61037:1997/A2:2000
(Amendment)Electricity metering - Tariff and load control - Particular requirements for electronic ripple control receivers
- BACK
- 31-Mar-2000
- 31-May-2005
- 29.240.30
- 89/336/EEC
- MEE
Electricity metering - Tariff and load control - Particular requirements for electronic ripple control receivers
EN following parallel vote * Superseded by EN 62052-21:2004 and EN 62054-11:2004
Messung der elektrischen Energie - Tarif- und Laststeuerung - Besondere Anforderungen für elektronische Rundsteuerempfänger
Comptage de l'électricité - Tarification et contrôle de charge - Prescriptions particulières pour récepteurs électroniques de télécommande centralisée
Electricity metering - Tariff and load control - Particular requirements for electronic ripple control receivers - Amendment A2 (IEC 61037:1990/A2:1998)
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 61037:1997/A2:2000
01-april-2000
Electricity metering - Tariff and load control - Particular requirements for
electronic ripple control receivers - Amendment A2 (IEC 61037:1990/A2:1998)
Electricity metering - Tariff and load control - Particular requirements for electronic ripple
control receivers
Messung der elektrischen Energie - Tarif- und Laststeuerung - Besondere
Anforderungen für elektronische Rundsteuerempfänger
Comptage de l'électricité - Tarification et contrôle de charge - Prescriptions particulières
pour récepteurs électroniques de télécommande centralisée
Ta slovenski standard je istoveten z: EN 61037:1992/A2:1998
ICS:
29.240.30 Krmilna oprema za Control equipment for electric
elektroenergetske sisteme power systems
SIST EN 61037:1997/A2:2000 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
--------
...
This May Also Interest You
IEC 62351-3:2023 specifies how to provide confidentiality, integrity protection, and message level authentication for protocols that make use of TCP/IP as a message transport layer and utilize Transport Layer Security when cyber-security is required. This may relate to SCADA and telecontrol protocols, but also to additional protocols if they meet the requirements in this document.
IEC 62351-3 specifies how to secure TCP/IP-based protocols through constraints on the specification of the messages, procedures, and algorithms of Transport Layer Security (TLS) (TLSv1.2 defined in RFC 5246, TLSv1.3 defined in RFC 8446). In the specific clauses, there will be subclauses to note the differences and commonalities in the application depending on the target TLS version. The use and specification of intervening external security devices (e.g., "bump-in-the-wire") are considered out-of-scope.
In contrast to previous editions of this document, this edition is self-contained in terms of completely defining a profile of TLS. Hence, it can be applied directly, without the need to specify further TLS parameters, except the port number, over which the communication will be performed. Therefore, this part can be directly utilized from a referencing standard and can be combined with further security measures on other layers. Providing the profiling of TLS without the need for further specifying TLS parameters allows declaring conformity to the described functionality without the need to involve further IEC 62351 documents.
This document is intended to be referenced as a normative part of other IEC standards that have the need for providing security for their TCP/IP-based protocol exchanges under similar boundary conditions. However, it is up to the individual protocol security initiatives to decide if this document is to be referenced.
The document also defines security events for specific conditions, which support error handling, security audit trails, intrusion detection, and conformance testing. Any action of an organization in response to events to an error condition described in this document are beyond the scope of this document and are expected to be defined by the organization’s security policy.
This document reflects the security requirements of the IEC power systems management protocols. Should other standards bring forward new requirements, this document may need to be revised.
This second edition cancels and replaces the first edition published in 2014, Amendment 1:2018 and Amendment 2:2020. This edition constitutes a technical revision.
This edition includes the following significant technical changes with respect to the previous edition:
a) Inclusion of the TLSv1.2 related parameter required in IEC 62351-3 Ed.1.2 to be specified by the referencing standard. This comprises the following parameter:
• Mandatory TLSv1.2 cipher suites to be supported.
• Specification of session resumption parameters.
• Specification of session renegotiation parameters.
• Revocation handling using CRL and OCSP.
• Handling of security events.
b) Inclusion of a TLSv1.3 profile to be applicable for the power system domain in a similar way as for TLSv1.2 session.
- Standard52 pagesEnglish languagesale 10% offe-Library read for×1 day
This part of IEC 62351 defines the application authentication mechanism (A-profile) specifying messages, procedures and algorithms for securing the operation of all protocols based on or derived from IEC 60870-5: Telecontrol Equipment and Systems - Transmission Protocols.
This Standard applies to at least those protocols listed in Table 1.
[Table 1]
The initial audience for this International Standard is intended to be the members of the working groups developing the protocols listed in Table 1.
For the measures described in this standard to take effect, they must be accepted and referenced by the specifications for the protocols themselves. This document is written to enable that process. The working groups in charge of take this standard to the specific protocols listed in Table 1 may choose not to do so.
The subsequent audience for this specification is intended to be the developers of products that implement these protocols.
Portions of this standard may also be of use to managers and executives in order to understand the purpose and requirements of the work.
This document is organized working from the general to the specific, as follows:
- Clauses 2 through 4 provide background terms, definitions, and references.
- Clause 5 describes the problems this specification is intended to address.
- Clause 6 describes the mechanism generically without reference to a specific protocol.
- Clauses 7 and 8 describe the mechanism more precisely and are the primary normative part of this specification.
- Clause 9 define the interoperability requirements for this authentication mechanism.
- Clause 10 describes the requirements for other standards referencing this specification
Unless specifically labelled as informative or optional, all clauses of this specification are normative.
- Standard126 pagesEnglish languagesale 10% offe-Library read for×1 day
The IEC 61970-401 document describes how the IEC 61970-450 to -499, IEC TS 61970-600 and IEC 61970-600 profile standards as well as any other CIM based profile specifications are structured and created. Profile documents describe a subset of the canonical CIM dedicated to a specific data exchange, the canonical CIM is described in the IEC 61970-300 series documents as well as the IEC 61968-11.
Rules for creation of canonical CIM is outside the scope of this document.
The IEC 61970-401 document specifies the structure of a profile specification and the rules for creating the subsets from the canonical CIM. The guiding principle for the profiling method is that the information described by a profile is a true subset of the canonical CIM and retain class, role and attribute names from the canonical CIM. The data types in CIM are described by classes stereotyped Primitive or CIMDatatype that is a composition of three attributes value, unit and multiplier. The main objective being that different datasets (see section 3) exchanged using different profiles based on canonical CIM solely rely on the definitions and basic principles of the canonical CIM which is a key to make interoperability efforts feasible. This also enables different profiles to relate data between them by using the canonical CIM as a hub and supports a reader of a data set or a message to easily find descriptions of elements in both the profile and the canonical CIM. The support for relating data in different data sets or messages described by different profiles is required when data is divided across different data sets governed by different profiles. Such use cases are defined for network models where the network description is separated from the operational conditions of the network (seen as an input) and the results.
There are several languages that can describe profiles, e.g. UML (serialized as XMI), RDFS, Ecore or OWL. UML includes a graphical language that is implemented by UML editors. OWL does not have a graphical language, but several editors exist that support the display and editing of OWL data. The language in which a profile is described is outside the scope of this specification as well as how profiles are presented and edited in user interfaces. Relevant specifications are referenced in section 2.
A profile in UML is described by classes, attributes, associations and roles, the common way to describe information in UML. The UML language also include the concept of stereotypes and tagged values that enables custom extensions of the UML language. Hence profiling with UML means copying and updating classes, attributes, associations and stereotypes from the canonical CIM. A profile in OWL is described by classes and properties. There are two types of OWL properties matching with UML attributes and UML roles. Profiling in OWL means creating OWL classes and properties by selecting UML classes, attributes, and roles from canonical CIM the same way as it is done for profiling with UML. This specification standardizes the operations used to create the profile elements from the canonical CIM. As canonical CIM is described in UML the operations are described in the terms of UML classes, attributes and roles. There is a mapping between UML and OWL so either language can be used to describe the created profiles.
This specification support profiles describing data exchanged with CIMXML files according to IEC 61970-552. But other formats are also supported if the exchanged data comply with profiles created according to this document.
Tools that process data described by profiles created according to this document will need a machine readable version of the profiles, also called syntactical profile. IEC 61970-501 is an RDFS based serialization intended for this. Hence profiling tools shall support the generation of profiles in the IEC 61970-501 serialisation format. [...]
- Standard36 pagesEnglish languagesale 10% offe-Library read for×1 day
1.1 General
This International Standard is Part 100 of IEC 61968. It defines how messages may be exchanged between co-operating systems in order to facilitate the transfer of application-specific data. Such application-specific data include but are not limited to the message payloads defined in IEC 61968 (Parts 3-9 and Part 13), IEC 61970 and IEC 62325.
1.2 About This International Standard
This International Standard provides normative definitions for:
- a set of message archetypes (clause 5);
- a set of message exchange patterns that both sending and receiving systems are expected to implement (clause 6);
- the exact format of the messages that are to be transmitted over the various integration technologies including a precise description of the information that each message must contain (clause 7);
- a set of constraints and conventions to which applications must adhere in order to facilitate message exchange using IEC 61968-100 (clause 8);
- the details of how IEC 61968-100 messages should be implemented using various underlying transport mechanisms (clause 9).
1.3 What is not covered by this International Standard
Security considerations lie outside the scope of IEC 61968-100. This document defers to the IEC 62351 series for definitions and practices relating to the secure transmission of messages.
1.4 Future Considerations
1.4.1 Choice of Encoding Mechanisms
IEC 61968-100:2021 prescribes XML as the normative encoding mechanism for all messages defined by this International Standard.
Future editions of IEC 61968-100 may specify additional normative encoding methods including support for IEC 62361-104. The latter defines encodings to facilitate the exchange of information in the form of JSON documents whose semantics are defined by the IEC CIM and whose syntax is defined by an IETF JSON schema.
1.4.2 Choice of Web Service Technologies
IEC 61968-100:2021 provides normative definitions for the use of SOAP Web Services (clause 9.2) and Java Messaging Service (clause 9.3) for the transport of messages.
Future editions of IEC 61968-100 may specify additional normative web service technologies such as REST.
- Standard251 pagesEnglish languagesale 10% offe-Library read for×1 day
This part of IEC 62325 specifies a UML package for the HVDC Link scheduling business
process and its associated document contextual models, assembly models and XML schemas
for use within the European style electricity markets.
This part of IEC 62325 is based on the European style market contextual model
(IEC 62325-351). The business process covered by this part of IEC 62325 is described in
Subclause 5.3.
The relevant aggregate core components (ACCs) defined in IEC 62325-351 have been
contextualised into aggregated business information entities (ABIEs) to satisfy the requirements
of the European style market HVDC Link scheduling business process.
- Standard56 pagesEnglish languagesale 10% offe-Library read for×1 day
- Amendment9 pagesEnglish languagesale 10% offe-Library read for×1 day
- Draft530 pagesEnglish languagesale 10% offe-Library read for×1 day
The specifications of this document refer to general, respectively core, communication
requirements of the application functions in all domains of power utility automation systems.
Dedicated communication requirements and most examples of application functions in this
document are from the domain substation automation but may be reused in or extended to other
domains within power utility automation systems. Note that sometimes instead of the term
substation automation domain the term substation domain is used, especially if both the
switchyard devices (primary system) and the automation system (secondary system) are
regarded.
The description of the application functions is not used to standardize these functions, but to
identify communication requirements between Intelligent Electronic Devices (IEDs) hosting
these functions within plants and substations in the power system, between such stations (e.g.
between substation for line protection) and between the plant or substation and higher-level
remote operating places (e.g. network control centres) and maintenance places. In addition
interfaces to remote technical services (e.g. maintenance centres) are considered. The general
scope is the communication requirements for power utility automation systems. The basic goal
is interoperability for all interactions providing a seamless communication system for the overall
power system management. Another prerequisite for interoperability is a commonly defined
method for time synchronization.
Standardizing application functions and their implementation is completely outside the scope of
this document. Therefore, it cannot be assumed a single philosophy of allocating application
functions to devices. To support the resulting request for free allocation of these functions, a
proper breakdown of these functions into parts relevant for communication is defined. The
exchanged data and their required performance are defined.
The same or similar IEDs from substations like protective and control devices are found in other
domains like power plants also. Using this document for such devices in these plants facilitates
the system integration e.g. between the power plant control and the related substation
automation system. For some of such other application domains like wind power plants, hydro
power plants and distributed energy resources specific standard parts according to the
IEC 61850 series have been already defined and published.
- Amendment80 pagesEnglish languagesale 10% offe-Library read for×1 day
This part of IEC 61970 belongs to the IEC 61970-450 to IEC 61970-499 series that, taken as a
whole, defines at an abstract level the content and exchange mechanisms used for data
transmitted between power system analyses applications, control centres and/or control centre
components.
The purpose of this document is to rigorously define the subset of classes, class attributes, and
roles from the CIM necessary to describe the result of state estimation, power flow and other
similar applications that produce a steady-state solution of a power network, under a set of use
cases which are included informatively in this document.
This document is intended for two distinct audiences, data producers and data recipients, and
can be read from those two perspectives. From the standpoint of model export software used
by a data producer, the document defines how a producer may describe an instance of a
network case in order to make it available to some other program. From the standpoint of a
consumer, the document defines what that importing software must be able to interpret in order
to consume power flow cases.
There are many different use cases for which use of this document is expected and they differ
in the way that the document will be applied in each case. Implementers are expected to
consider what use cases they wish to cover in order to know the extent of different options they
must cover. As an example, the profiles defined in this document will be used in some cases to
exchange starting conditions rather than solved conditions, so if this is an important use case,
it means that a consumer application needs to be able to handle an unsolved state as well as
one which has met some solution criteria
- Standard110 pagesEnglish languagesale 10% offe-Library read for×1 day
This part of IEC 61970-600 defines the profiles included in the Common Grid Model Exchange
Standard (CGMES) that are based on IEC 61970-450-series and IEC 61968-13 profiles. This
document refers to the IEC 61970-450-series and IEC 61968-13 profiles only in cases where
they are identical. If the referenced profile is not yet published, this document includes the
profile definition and related constraints’ definitions. In the case where a CGMES profile makes
restriction on the referenced profile, the restriction is defined in this document.
The equipment boundary profile (EQBD) is the only profile that is not part of IEC 61970-450-
series and IEC 61968-13 profiles. This profile is deprecated as modifications have been made
to align between EQBP and the equipment profile (EQ). Although the updated EQBD is
addressing the requirement that boundary also can be located inside a substation, which will
be the case for many Distribution System Operators (DSOs), additional information would need
to be exchanged. For instance, system integrity protection schemes, that can be shared by
multiple utility would require another way of boundary handling. In this document EQBD is
included in CGMES only to create better backwards compatibility with previous version of the
CGMES.
The machine-readable documentation that supports model driven development of the profiles
defined in this part are generated as Resource Description Framework Schema (RDFS)
according to IEC 61970-501:2006 (with some extension) and IEC 61970-501:ED2 when
published.
- Standard879 pagesEnglish languagesale 10% offe-Library read for×1 day
This document is one of the IEC 61970-450 to 499 series that, taken as a whole, defines at an abstract level the content and exchange mechanisms used for data transmitted between control centres and/or control centre components, such as power systems applications.
The purpose of this document is to define the subset of classes, class attributes, and roles from the CIM necessary to execute state estimation and power flow applications. The North American Electric Reliability Council (NERC) Data Exchange Working Group (DEWG) Common Power System Modelling group (CPSM) produced the original data requirements, which are shown in Annex E. These requirements are based on prior industry practices for exchanging power system model data for use primarily in planning studies. However, the list of required data has been extended starting with the first edition of this standard to facilitate a model exchange that includes parameters common to breaker-oriented applications. Where necessary this document establishes conventions, shown in Clause 6, with which an XML data file must comply in order to be considered valid for exchange of models.
This document is intended for two distinct audiences, data producers and data recipients, and may be read from two perspectives.
From the standpoint of model export software used by a data producer, the document describes a minimum subset of CIM classes, attributes, and associations which must be present in an XML formatted data file for model exchange. This standard does not dictate how the network is modelled, however. It only dictates what classes, attributes, and associations are to be used to describe the source model as it exists.
- Standard277 pagesEnglish languagesale 10% offe-Library read for×1 day
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.