Abstract

IEC PAS 61850-90-28:2026, which is a Publicly Available Specification, specifies the expected behavior and associated documentation related to the validation of received GOOSE and SV messages. It considers engineering rules and guidance to ensure that the communication configuration process is well designed for this validation. Conformance statements related to this validation are also considered.
This document considers subscribers claiming conformance to latest editions of the IEC 61850 series in combination with publishers claiming conformance to any previous version and revision of the IEC 61850 series.

Status
Published
Publication Date
13-Oct-2026
Drafting Committee
WG 10 - TC 57/WG 10
Current Stage
PPUB - Publication issued
Start Date
14-Oct-2026
Completion Date
25-Sep-2026

Buy Documents

Technical specification

iecpas61850-90-28{ed1.0}en - IEC PAS 61850-90-28:2026 - Communication networks and systems for power utility automation - Part 90-28: Specification for subscriber IED to validate received GOOSE and SV messages

ISBN:978-2-8327-1533-8
Release Date:14-Oct-2026
English language (77 pages)
sale 15% off
Preview
sale 15% off
Preview

IEC PAS 61850-90-28:2026 is an IEC Publicly Available Specification for power utility automation. It specifies the expected behavior and related documentation for validating received GOOSE and SV messages in subscriber IEDs, and it sets out the engineering guidance and conformance statements needed to make that validation practical.

What does IEC PAS 61850-90-28:2026 specify?

IEC PAS 61850-90-28:2026 specifies how a subscriber IED validates received GOOSE and SV messages, and how that validation is documented, engineered and tested. It is written for subscriber IEDs that claim conformance to the latest editions of the IEC 61850 series, while publishers may claim conformance to any previous version and revision of the IEC 61850 series.

The document is organized from the general scope through terms, validation principles, use cases, engineering considerations, message parameters, supervision and data model preliminaries, then PIXIT entries and test material. Its main clauses cover:

  • scope and namespace information
  • normative references
  • terms and abbreviations
  • validation principles and use cases
  • engineering process considerations
  • message parameters and validation
  • handling, supervision and loss detection
  • logical node preliminaries and data semantics
  • PIXIT entries
  • conformance statements and abstract test cases in Annexes C and D
AnnexWhat it covers
Annex CConformance statements for GOOSE and SV message validation
Annex DAbstract test cases for GoCB and SVCB subscribers

What are the key requirements of IEC PAS 61850-90-28:2026?

IEC PAS 61850-90-28:2026 focuses on filtering, validation, supervision and testability. In practice, the standard is about making sure a subscriber IED accepts only the messages it expects, reports configuration problems clearly, and exposes enough state for testing and diagnostics.

  • Clause 7 requires efficient filtering at the communication layer. The subscriber IED shall use the destination multicast MAC address and APPID for filtering, and unexpected GOOSE and SV messages shall be rejected before application processing. This matters because it keeps invalid or irrelevant traffic from affecting protection or control functions.

  • Clause 7 requires only fully validated data to reach the application layer. Messages that do not match the expected subscription are not to be forwarded for application processing, and the user should be informed when validation affects the subscription state. In practice, this means validation is not only a network function - it is also part of operational diagnosis.

  • Clause 7 requires common validation rules and documented exceptions. The same major validation rules shall be implemented in all subscriber IEDs, while any additional rules used by a specific IED shall be documented in PIXIT. This gives buyers and test labs a way to compare implementations and to know what extra checks a device performs.

  • Clause 9 requires system-level engineering awareness. Any GoCB or SVCB change made by an IED Configuration Tool shall be considered by the System Configuration Tool (SCT), and the SCT shall know the subscriber IEDs for each publisher. The SCL file carries this through the <IEDName> elements under GSEControl and SampledValueControl, so configuration tools can keep publisher and subscriber settings aligned.

  • Clause 10 defines the validation points for GOOSE and SV messages. For Layer 2 traffic, the standard covers destination MAC address, source MAC address, priority tagging/Virtual LAN, Ethertype, APPID and APDU length. For GOOSE APDU and SV APDU content, it covers fields such as gocbRef, datSet, goID, stNum, sqNum, confRev, ndsCom, numDatSetEntries, svID, smpCnt, smpSynch, smpRate, smpMod and gmIdentity. This means validation is not limited to network headers - it also checks whether the payload matches the expected control block and dataset.

  • Clause 10.5 points to replay protection, and security handling is tied to IEC 62351-6:2020. Where security is not supported, the security-related reserved fields are ignored according to the conformance statements; where security is supported, IEC 62351-6 applies. That lets implementations separate normal validation from security-enabled deployments without changing the validation concept.

  • Clause 11 requires supervision of active subscriptions. The document strongly recommends implementing LGOS and LSVS for GoCB and SVCB subscriptions, and SimSt when simulated messages can be processed. It also defines subscription state machines and the loss-of-publisher behavior, so a device can show whether a subscription is active, waiting, misconfigured or timed out.

  • Clause 12 adds the logical node preliminaries needed for diagnostics. It defines logical node classes such as LGOSExt and LSVSExt, and data object semantics such as SynChgCnt and TmoutExpCnt. In practice, these objects give the subscriber a way to expose counters and states that operators and test systems can read.

  • Clause 13 and Annex D make the document testable. PIXIT entries declare implementation behavior such as acceptance windows, timeout behavior and additional checks, while Annex D updates abstract test cases for conformance testing. This matters because the standard is designed not just as guidance, but as a basis for repeatable testing.

What terms does IEC PAS 61850-90-28:2026 define?

IEC PAS 61850-90-28:2026 defines the core message roles and error conditions used in validation. These definitions are important because the validation logic depends on whether a message is expected, simulated, missing or invalid.

  • publisher - an entity that sends messages without being aware of the subscriber or subscribers.
  • subscriber - an entity that receives and accepts expected messages while being aware of the publisher configuration.
  • operational GOOSE or SV message - the normal GOOSE or SV message published by an IED in usual operation.
  • simulated GOOSE or SV message - a GOOSE or SV message from a test entity for use in simulation mode, marked so it is distinct from operational traffic.
  • missing GOOSE message - a GOOSE message that was expected but not received while the subscription is active.
  • invalid SV message - an SV message that matches a configured SVCB subscription but contains the wrong configuration or an error.
  • message filtering - the way an IED efficiently discards messages that do not correspond to an expected subscription.
  • GOOSE control block (GoCB) - the control block used for GOOSE publication and subscription supervision.
  • sampled value control block (SVCB) - the control block used for SV publication and subscription supervision.

Who uses IEC PAS 61850-90-28:2026?

IEC PAS 61850-90-28:2026 is used by people who design, configure, test and buy IEC 61850-based equipment in power utility automation. The document is especially relevant where subscriber behavior, supervision and commissioning need to be checked against a shared validation model.

Typical users include:

  • subscriber IED vendors implementing GOOSE and SV validation
  • publisher IED vendors whose message formats must be accepted by subscribers
  • system configurator tool developers working with SCL, SCD and SED files
  • commissioning and protection engineers checking that subscriptions match the intended system design
  • diagnostic and supervision tool developers verifying deployed configurations
  • conformance test labs and certification bodies using the PIXIT entries and abstract test cases
  • buyers and quality managers comparing what a device validates and what it reports

Which standards are used with IEC PAS 61850-90-28:2026?

IEC PAS 61850-90-28:2026 is built on other parts of IEC 61850 and on the security part used for message protection. The introduction says the specification provides new requirements for configuration description, data model and abstract services, communication service mappings, and conformance testing.

ReferenceWhat it contributes
IEC 61850-6Configuration description language for communication in electrical substations related to IEDs
IEC 61850-7-1:2011 and AMD1:2020Basic communication structure - principles and models
IEC 61850-7-2:2010 and AMD1:2020Abstract communication service interface (ACSI)
IEC 61850-7-3Common data classes
IEC 61850-7-4Compatible logical node classes and data object classes
IEC 61850-8-1:2011 and AMD1:2020Mappings to MMS and to ISO/IEC 8802-3
IEC 61850-9-2Sampled values over ISO/IEC 8802-3
IEC 61850-10Conformance testing
IEC 62351-6:2020Security for IEC 61850

What does the IEC PAS 61850-90-28:2026 document contain?

IEC PAS 61850-90-28:2026 contains both descriptive material and implementation-oriented structures. It includes namespace tracking information, code component distribution details, engineering examples using SCL extracts, message parameter breakdowns for Layer 2 and routable GOOSE and SV, and replay protection guidance.

It also contains statechart figures for GoCB and SVCB subscription handling, class diagrams for the logical node packages, and tables that define data object names, diagnostic enumerations and PIXIT entries. Annex C turns the validation rules into conformance statements, and Annex D turns them into abstract test cases for GoCB and SVCB subscribers.

Buy Documents

Technical specification

iecpas61850-90-28{ed1.0}en - IEC PAS 61850-90-28:2026 - Communication networks and systems for power utility automation - Part 90-28: Specification for subscriber IED to validate received GOOSE and SV messages

ISBN:978-2-8327-1533-8
Release Date:14-Oct-2026
English language (77 pages)
sale 15% off
Preview
sale 15% off
Preview

Get Certified

Connect with accredited certification bodies for this standard

ANCE

Mexican certification and testing association.

EMA Mexico Verified

Intertek Slovenia

Intertek testing, inspection, and certification services in Slovenia.

UKAS Slovenia Verified

LNE (Laboratoire National de Métrologie et d'Essais)

French national laboratory for metrology and testing.

COFRAC France Verified

Sponsored listings

Frequently Asked Questions

IEC PAS 61850-90-28:2026 is a technical specification published by the International Electrotechnical Commission (IEC). Its full title is "Communication networks and systems for power utility automation - Part 90-28: Specification for subscriber IED to validate received GOOSE and SV messages". This standard covers: IEC PAS 61850-90-28:2026, which is a Publicly Available Specification, specifies the expected behavior and associated documentation related to the validation of received GOOSE and SV messages. It considers engineering rules and guidance to ensure that the communication configuration process is well designed for this validation. Conformance statements related to this validation are also considered. This document considers subscribers claiming conformance to latest editions of the IEC 61850 series in combination with publishers claiming conformance to any previous version and revision of the IEC 61850 series.

IEC PAS 61850-90-28:2026, which is a Publicly Available Specification, specifies the expected behavior and associated documentation related to the validation of received GOOSE and SV messages. It considers engineering rules and guidance to ensure that the communication configuration process is well designed for this validation. Conformance statements related to this validation are also considered. This document considers subscribers claiming conformance to latest editions of the IEC 61850 series in combination with publishers claiming conformance to any previous version and revision of the IEC 61850 series.

IEC PAS 61850-90-28:2026 is classified under the following ICS (International Classification for Standards) categories: 33.200 - Telecontrol. Telemetering. The ICS classification helps identify the subject area and facilitates finding related standards.

IEC PAS 61850-90-28:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.

Standards Content (Sample)


IEC PAS 61850-90-28 ®
Edition 1.0 2026-10
PUBLICLY AVAILABLE
SPECIFICATION
Communication networks and systems for power utility automation -
Part 90-28: Specification for subscriber IED to validate GOOSE and SV
messages
ICS 33.200  ISBN 978-2-8327-1533-8

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
The world's leading online dictionary on electrotechnology,
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
CONTENTS
FOREWORD . 5
INTRODUCTION . 7
1 Scope . 8
1.1 General . 8
1.2 Published versions of the standard and related namespace names . 8
1.3 Identification of the namespace . 8
1.4 Code Component distribution . 9
2 Normative references . 10
3 Terms and definitions . 10
4 Abbreviated terms . 13
5 GOOSE and SV messages validation principle . 13
6 GOOSE and SV messages validation use cases . 14
6.1 Use case 1: Upgrade of system communication configuration using SCD or
SED without updating all subscriber and/or publisher IEDs . 14
6.2 Use case 2: Extension of substation with new bays . 14
6.3 Use case 3: Replacement of an IED with same configuration as previous one . 14
6.4 Use case 4: Wrong configuration loaded into an IED . 14
6.5 Use case 5: Change configuration of an IED not considered by system
configuration . 14
6.6 Use case 6: Simulation of IED in the network sending same GOOSE and SV
messages as operational IED without simulation flag . 14
6.7 Use case 7: Simulation of IED in the network sending GOOSE or SV
messages with simulation flag configured differently as the operational IED . 15
6.8 Use case 8: Use of diagnostic/supervision tool to validate the deployment of
a configuration in a system with GoCB and SVCB publisher/subscriber . 15
7 GOOSE and SV messages validation requirements . 16
8 GOOSE and SV messages validation principle . 16
9 Engineering process consideration . 17
9.1 Configuration of GoCB/SVCB publishers and subscribers . 17
9.2 Impact of the change of the configuration of publisher IEDs on subscriber
IEDs . 17
9.2.1 General . 17
9.2.2 Destination MAC address and APPID . 17
9.2.3 VLAN information . 18
9.2.4 Minimum time, applying to GOOSE message . 18
9.2.5 Maximum time, applying to GOOSE message . 18
9.2.6 Support of fixed offset. 18
9.2.7 Support of security . 19
9.2.8 Datset information . 19
9.2.9 Rule for configuration revision (ConfRev) . 19
10 GOOSE and SV message parameters and its validation . 20
10.1 Header information for Layer 2 GOOSE and SV messages . 20
10.1.1 Destination MAC Address . 20
10.1.2 Source MAC Address. 20
10.1.3 Priority tagging/Virtual LAN . 21
10.1.4 Ethertype . 22
10.1.5 APPlication IDentifier (APPID) . 22
10.1.6 APDU Length . 23
10.1.7 Reserved . 23
10.2 Header information for Routable GOOSE and SV messages . 23
10.2.1 Transport Layer / Destination multicast . 23
10.2.2 Priority tagging/Virtual LAN . 23
10.2.3 Session Identifier (SI) . 23
10.2.4 Session Header . 23
10.2.5 Session User Information . 24
10.2.6 Simulation . 25
10.2.7 APPlication IDentifier (APPID) . 25
10.2.8 APDU Length . 25
10.3 GOOSE APDU . 25
10.3.1 GOOSE Control Block Reference (gocbRef) . 25
10.3.2 Time Allowed to Live (timeAllowedtoLive) . 26
10.3.3 Data Set Reference (datSet) . 26
10.3.4 GOOSE IDentifier (goID) . 27
10.3.5 GOOSE Timestamp (T) . 28
10.3.6 State Number (stNum) . 28
10.3.7 Sequence Number (sqNum) . 29
10.3.8 Simulation (simulation) . 29
10.3.9 Configuration Revision (confRev). 29
10.3.10 Needs Commissioning (ndsCom) . 30
10.3.11 Number of Data Set Members (numDatSetEntries) . 30
10.3.12 GOOSE Data (allData) . 30
10.4 SV APDU . 31
10.4.1 Number of ASDUs (noASDU) . 31
10.4.2 Security (security) . 32
10.4.3 SV IDentifier (svID) . 32
10.4.4 Data Set Reference (datSet) . 32
10.4.5 Sample Counter (smpCnt) . 32
10.4.6 Configuration Revision (confRev). 33
10.4.7 Refresh time (refrTm) . 33
10.4.8 Sample synchronization (smpSynch) . 33
10.4.9 Sample rate (smpRate) . 33
10.4.10 Sequence of data (SequenceOfData) . 34
10.4.11 Sampling mode (smpMod) . 34
10.4.12 Synchronization source IDentifier (gmIdentity) . 34
10.4.13 Optional fields of SV message . 34
10.5 GOOSE and SV messages replay protection . 35
11 Handling of GOOSE and SV messages validation . 35
11.1 GOOSE and SV messages validation modelling . 35
11.2 GoCB subscription state . 35
11.2.1 GoCB subscription state machine . 35
11.2.2 Status of the GoCB subscription based on LGOS DO . 38
11.3 SVCB subscription state . 39
11.3.1 SVCB subscription state machine . 39
11.3.2 Status of the SVCB subscription based on LSVS DO . 42
11.4 Loss of SVCB publisher . 43
12 Data Model – Logical node preliminaries . 44
12.1 Logical node classes (LogicalNodes_90_28) . 44
12.1.1 General . 44
12.1.2 System logical nodes (LNGroupL_90_28) . 45
12.2 Data object name semantics and enumerations . 51
12.2.1 Data semantics . 51
12.2.2 Enumerated data attribute types . 53
13 PIXIT entries . 57
13.1 General . 57
13.2 PIXIT entries required for GOOSE message validation . 57
13.2.1 PIXIT entry for checks on GOOSE data . 57
13.2.2 PIXIT entry for stNum acceptance in GoCB subscriber model . 57
13.2.3 PIXIT entry for sqNum acceptance in GoCB subscriber model . 58
13.2.4 PIXIT entry for misconfigured GoCB subscription . 58
13.2.5 PIXIT entry for timeout on first GOOSE message . 58
13.2.6 PIXIT entry for Ed1 Test GOOSE message in GoCB subscriber model . 58
13.2.7 PIXIT entry for additional checked performed for GOOSE message
validation . 59
13.3 PIXIT entries required for SV message validation . 59
13.3.1 PIXIT entry for misconfigured SVCB subscription . 59
13.3.2 PIXIT entry for timeout on first SV message . 59
13.3.3 PIXIT entry for additional checks performed for SV message validation . 59
Annex A (normative) Handling of Ed1 Test and Ed2 Simulation GOOSE parameters . 60
Annex B (informative) Support of IEC 62351-6 in SCL . 61
Annex C (informative) GOOSE and SV messages validation conformance statements . 62
C.1 General . 62
C.2 GOOSE message validation conformance statement. 62
C.3 SV message validation conformance statement . 63
Annex D (normative)  Abstract test cases . 66
D.1 General . 66
D.2 GoCB subscriber test cases . 66
D.3 SVCB subscriber test cases . 72
Bibliography . 77

Figure 1 – Concept of layers applying to process of GOOSE and SV messages . 16
Figure 2 – Statechart diagram GOOSE_90_28::GoCB subscription state machine . 36
Figure 3 – Statechart diagram SMV_90_28::SVCB subscription state machine . 40
Figure 4 – Class diagram LogicalNodes_90_28::LogicalNodes_90_28 . 44
Figure 5 – Class diagram LNGroupL_90_28::LNGroupLExt_90_28 . 45
Figure 6 – Class diagram DOEnums_90_28::DOEnums_90_28 . 53

Table 1 – Tracking information of (Tr)IEC 61850-90-28:2024A namespace building-up . 8
Table 2 – Published version . 8
Table 3 – Attributes of (Tr)IEC 61850-90-28:2024A namespace . 9
Table 4 – Recommended multicast MAC address for GOOSE and SV messages . 20
Table 5 – Reserved APPID for GOOSE and SV messages . 22
Table 6 – GOOSE conformance statement entry for expiration timer . 26
Table 7 – DO SimSt of updated SubscriptionSupervisionLN . 35
Table 8 – Update of NdsCom description . 38
Table 9 – Subscription state interpretation from DO NdsCom, GoDiag and St . 39
Table 10 – Update of NdsCom description . 42
Table 11 – Subscription state interpretation from DO NdsCom, SvDiag and St . 43
Table 12 – Data objects of SubscriptionSupervisionLNExt . 46
Table 13 – Data objects of LGOSExt . 47
Table 14 – Data objects of LSVSExt . 49
Table 15 – Name and description of data objects defined in classes of
LogicalNodes_90_28 package . 51
Table 16 – Literals of GoDiagKind . 54
Table 17 – Literals of SvDiagKind . 56
Table 18 – PIXIT entry for checks on GOOSE data . 57
Table 19 – PIXIT entry for stNum acceptance in GoCB subscriber model . 57
Table 20 – PIXIT entry for sqNum acceptance in GoCB subscribe model . 58
Table 21 – PIXIT entry for misconfigured GoCB subscription . 58
Table 22 – PIXIT entry for timeout on first GOOSE message . 58
Table 23 – PIXIT entry for Ed1 Test GOOSE message in GoCB subscriber model . 58
Table 24 – PIXIT entry for additional checked performed for GOOSE message
validation . 59
Table 25 – PIXIT entry for misconfigured SVCB subscription . 59
Table 26 – PIXIT entry for timeout on first SV message . 59
Table 27 – PIXIT entry for additional checked performed for SV message validation . 59
Table C.1 – GOOSE message validation conformance statement . 62
Table C.2 – SV message validation conformance statement . 64
Table D.1 – Update of GOOSE subscribe positive test cases . 66
Table D.2 – Update of GoCB subscriber negative test cases. 68
Table D.3 – Update required for SVCB subscriber positive test cases . 72
Table D.4 – Update of SVCB subscriber negative test cases. 73

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
Communication networks and systems for power utility automation -
Part 90-28: Specification for subscriber IED
to validate GOOSE and SV messages

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 61850-90-28 has been prepared by TC 57: Power systems management and associated
information exchange. It is a Publicly Available Specification.
The text of this Publicly Available Specification is based on the following documents:
Draft Report on voting
57/2923/DPAS 57/2966/RVDPAS
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this Publicly Available Specification is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
A list of all parts in the IEC 61850 series, published under the general title Communication
networks and systems for power utility automation, can be found on the IEC website.
This document includes Code Components i.e. components that are intended to be directly
processed by a computer.
Such content is any text found between the markers and , or
otherwise is clearly labelled in this document as a Code Component.
The purchase of this IEC document carries a copyright license for the purchaser to sell software
containing Code Components from this standard to end users either directly or via distributors,
subject to IEC software licensing conditions, which can be found at: http://www.iec.ch/CCv1.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
INTRODUCTION
GOOSE and SV messages carry critical data as measurements, trip signals, blocking signals,
etc. which are exchanged between IEDs. Those messages could cause a mis-operation if they
are processed when they should not be. Therefore, it becomes critical to make validation of
those messages more resilient to ensure that data forwarded to the application are the expected
ones.
Each vendor implements validation on different parameters of the GOOSE and SV messages.
Therefore validation has to be harmonized. In addition, this will make commissioning easier.
Issues caused by the engineering process or human error during operation is expected to be
detected by subscriber IED.
Efficient filtering of messages is expected to be implemented to achieve expected timing
performance.
IEDs must notify the user of any identified issues so they can be validated by testing.
The aim of this Publicly Available Specification is to provide new requirements related to
validation of GOOSE and SV messages for the IEC 61850 series:
– Part 6 for configuration description,
– Part 7-x for data model and abstract services,
– Part 8-1 and part 9-2 for specific communication service mappings,
– Part 10 for conformance testing
Once this document has been published, the affected parts of the core standards will be updated
with the results from this specification.
As it contains some description of the different parameters of the GOOSE and SV messages
and some recommendations, this document could be used as a guideline for implementation
too.
This document focuses on the validation and supervision of GOOSE and SV messages.

1 Scope
1.1 General
This of the IEC 61850 series, which is a Publicly Available Specification, specifies the expected
behavior and associated documentation related to the validation of received GOOSE and SV
messages. It considers engineering rules and guidance to ensure that the communication
configuration process is well designed for this validation. Conformance statements related to
this validation are also considered.
This document considers subscribers claiming conformance to latest editions of the IEC 61850
series in combination with publishers claiming conformance to any previous version and
revision of the IEC 61850 series.
1.2 Published versions of the standard and related namespace names
Table 1 shows all tracking information of (Tr)IEC 61850-90-28:2024A namespace building-up.
Table 1 – Tracking information of (Tr)IEC 61850-90-28:2024A namespace building-up
Attribute Content
Namespace IEC specific information
Version of the UML model used for generating the document (informative) WG10build26
Date of the UML model used for generating the document (informative) 2026-08-05
Autogeneration software name and version(informative) j61850DocBuilder 02.06bbeta
based on jCleanCim beta9.4
(derived from jCleanCim 02-02)

Table 2 provides a reference between all published editions, amendments or corrigenda of this
document and the full name of the namespace.
Table 2 – Published version
Edition Publication date Webstore Namespace
Edition 1.0 2025-xx IEC PAS 61850-90-28:2025 (Tr)IEC 61850-90-28:2024

1.3 Identification of the namespace
The namespace associated with this document is an NSD (Namespace Definition) file as
defined in IEC 61850-7-7.
NOTE The NSD files are distributed as a Full (complete machine-readable file) Code Component and as a Light
(reduced machine-readable content version) Code Component.
Table 3 shows all attributes of (Tr)IEC 61850-90-28:2024A namespace.
Table 3 – Attributes of (Tr)IEC 61850-90-28:2024A namespace
Attribute Content
Namespace nameplate
Namespace Identifier (Tr)IEC 61850-90-28
Version 2024
Revision A
Release 2
Full Namespace Name (Tr)IEC 61850-90-28:2024A
Full Code Component Name IEC_PAS_61850-90-28.NSD.2024A2.Full
Light Code Component Name IEC_PAS_61850-90-28.NSD.2024A2.Light
Namespace type transitional
Namespace dependencies
extends IEC 61850-7-4 version:2007 revision: B
Namespace transitional status
Future handling of namespace content The namespace (Tr)IEC 61850-90-28:2024A is considered as
"transitional" since the models are expected to be included in
further editions of IEC 61850. Extensions or modifications to the
model may occur when the model is merged into the International
Standard documents
1.4 Code Component distribution
Each Code Component is a ZIP package containing the electronic representation of the Code
Component itself, with a file describing the content of the package (IECManifest.xml).
The life cycle of a code component is not restricted to the life cycle of the related publication.
The publication life cycle goes through two stages, Version (corresponding to an edition) and
Revision (corresponding to an amendment). A third publication stage (Release) allows
publication of Code Component in case of urgent fixes of InterOp Tissues, thus without need to
publish an amendment.
Consequently new release(s) of the Code Component may be released, which supersede(s) the
previous release, and will be distributed through the IEC TC 57 web site at:
http://www.iec.ch/tc57/supportdocuments.
The latest version/release of the document will be found by selecting the file for the code
component with the highest value for VersionStateInfo e.g.
IEC_PAS_61850-90-28.NSD.{VersionStateInfo}.Light.{Light | Full}.zip.
For conformance testing, implementations should always use the latest downloadable Code
Components, as the Code Components may be subject to updates. See technical corrigenda
and XSD history files.
When the Code Components associated with this document have a full version and a light
version, the light version is freely accessible.
When the Code Components associated with this document have a full version only, the full
version is freely accessible.
The freely accessible Code Components are available on the IEC website for download at
https://www.iec.ch/tc57/supportdocuments, but the usage remains under the licensing
conditions.
2 Normative references
The following documents, in whole or in part, are normative reference for this document and
required for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
IEC 61850-6, Communication networks and systems for power utility automation - Part 6:
Configuration description language for communication in electrical substations related to IEDs
IEC 61850-7-1:2011, Communication networks and systems for power utility automation -
Part 7-1: Basic communication structure - Principles and models
IEC 61850-7-1:2011/AMD1:2020
IEC 61850-7-2:2010, Communication networks and systems for power utility automation -
Part 7-2: Basic information and communication structure - Abstract communication service
interface (ACSI)
IEC 61850-7-2:2010/AMD1:2020
IEC 61850-7-3, Communication networks and systems for power utility automation - Part 7-3:
Basic communication structure - Common data classes
IEC 61850-7-4, Communication networks and systems for power utility automation - Part 7-4:
Basic communication structure - Compatible logical node classes and data object classes
IEC 61850-8-1:2011, Communication networks and systems for power utility automation -
Part 8-1: Specific communication service mapping (SCSM) - Mappings to MMS (ISO 9506-1
and ISO 9506-2) and to ISO/IEC 8802-3
IEC 61850-8-1:2011/AMD1:2020
IEC 61850-9-2, Communication networks and systems for power utility automation - Part 9-2:
Specific communication service mapping (SCSM) - Sampled values over ISO/IEC 8802-3
IEC 61850-10, Communication networks and systems for power utility automation - Part 10:
Conformance testing
IEC 62351-6:2020, Power systems management and associated information exchange - Data
and communications security - Part 6: Security for IEC 61850
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
– IEC Electropedia: available at http://www.electropedia.org/
– ISO Online browsing platform: available at http://www.iso.org/obp
3.1
publisher
entity that sends messages without considering and being aware of the subscriber(s) of this
message
3.2
subscriber
entity that receives and accepts expected messages being aware of the publisher configuration
of this message
3.3
operational GOOSE or SV message
GOOSE or SV message published by an IED in a usual context
Note 1 to entry: This is the default kind of GOOSE and SV message.
3.4
simulated GOOSE or SV message
GOOSE or SV message published by a test entity to be used by subscriber operating in
simulation mode instead of operational GOOSE or SV message
Note 1 to entry: This message has to be distinct from operational message. To achieve that, it contains a simulation
property in the message. Simulated GOOSE and SV messages are used in a non-operational context.
3.5
duplicated GoCB/SVCB publisher
GoCB or SVCB publisher which publishes duplicated GOOSE or SV messages with different
source MAC Address
3.6
missing GOOSE message
GOOSE message which has not been received whereas subscription is active
Note 1 to entry: It could be detected because it leads to a jump in the expected sequence of the subscriber.
For example, latest received stNum is 'n' and latest received SqNum is 'm':
– subscriber receives stNum 'n'+1 and sqNum '1' OR
– subscriber receives stNum 'n'+2 and sqNum '0' OR
– subscriber receives stNum 'n' and sqNum 'm' + 2 …
In case of missing GOOSE message, GoCB subscription shall remain active because GOOSE message is received
before expiration timer.
3.7
double GOOSE message
two GOOSE messages which are identical, i.e. same header, same value of the simulation flag,
same stNum and same sqNum
Note 1 to entry: This issue could happen due to the network.
It could be detected if two consecutive GOOSE messages are received with the same state number and sequence
number. In case of detection of double GOOSE messages, the second received GOOSE message shall be discarded
but GoCB subscription shall remain active.
3.8
out of order GOOSE message
GOOSE message which is received out of the expected sequence
Note 1 to entry: It could be detected because it leads to receive a GOOSE message out of acceptance window of
the subscriber regarding stNum and sqNum.
For example, latest received stNum is 'n' and latest received SqNum is 'm':
– subscriber receives stNum 'n' and sqNum 'm-1' OR
– subscriber receives stNum 'n-1' and sqNum 'any' OR
– subscriber receives stNum 'n+5' and sqNum 'm' + 2 …
In case of out of order GOOSE message, GOOSE message is accepted or not depending on acceptance window.
GoCB subscription remains active until it leads to expiration timer.
3.9
no GOOSE message
situation where no GOOSE message is received at the startup of the subscription or at the end
of the expiration timer
Note 1 to entry: In case of no GOOSE message, GoCB subscription is inactive.
3.10
invalid GOOSE message
GOOSE message which corresponds to a configured GoCB subscription but has a wrong
configuration or contains an error in the message
Note 1 to entry: In case of invalid GOOSE message, GOOSE message shall be rejected and GoCB subscription
remains in its current state.
3.11
missing SV message
SV message which is not received by the subscriber
Note 1 to entry: It could be detected because it leads to a jump of smpCnt in the expected sequence of the
subscriber whereas smpSynch does not change.
For example, latest received smpCnt is 'n' and smpSynch is 'm':
– subscriber receives smpCnt 'n'+x and smpSynch is 'm'.
In case of missing SV, SVCB subscription shall remain active because SV is received before expiration timer.
3.12
double SV message
two SV messages which are received with the same configuration, the same value of the
simulation flag, the same smpCnt and the same smpSynch
Note 1 to entry: This issue could happen due to the network.
It could be detected if two consecutive SV messages are received with the same sample counter and sample
synchronization state. In case of detection of double SV messages, the second received SV message shall be
discarded but SVCB subscription shall remain active.
3.13
out of order SV message
SV message which is received out of the expected sequence of smpCnt while the smpSynch
and gmIdentity values remain unchanged
Note 1 to entry: It could be detected because it leads to a discontinuity in the sequence of smpCnt.
For example, latest received smpCnt is 'n', and smpSynch value is 1 or 2:
– subscriber receives smpCnt 'n-7' and same smpSynch and gmIdentity if relevant, OR
– subscriber receives smpCnt 'n+5' and same smpSynch and same gmIdentity if relevant.
In case of out-of-order SV message, SV message is accepted or not depending on the acceptance window. The
SVCB subscription remains active until it leads to an expiration timer.
3.14
no SV message
situation where no SV message is received at the startup of the subscription or at the end of
the loss of SVCB publisher
Note 1 to entry: In case of no SV message, SVCB subscription is inactive.
3.15
invalid SV message
SV message which corresponds to a configured SVCB subscription but has a wrong
configuration or contains an error in the message
Note 1 to entry: In case of invalid SV message, SV message shall be rejected and SVCB subscription remains in
its current state.
3.16
message filtering
way for an IED to efficiently discard messages that do not correspond to an expected
subscription
4 Abbreviated terms
APDU application protocol data unit
DMAC destination MAC address
GoCB GOOSE control block
GOOSE generic object oriented substation events
IED intelligent electronic device
MAC Media Access Control
MMS manufacturing message specification (ISO 9506)
PICS protocol implementation conformance statement
PIXIT protocol implementation extra information for testing
SCL system configuration language (IEC 61850-6)
SCD system configuration description
SCT system configurator tool
SED system exchange description
SV sampled value
SVCB sampled value control block
TAL time allowed to live
5 GOOSE and SV messages validation principle
Validation of GOOSE and SV messages is essential:
– to avoid any function maloperation
– to have a performant system
– to detect and inform on any configuration issue
GOOSE and SV messages subscription validation requires that
– publisher IEDs shall be conformance tested, and
– engineering tools used in the configuration workflow shall be conformance tested
This document considers
– subscriber IEDs and configuration tools claiming conformance to the latest editions of the
IEC 61850 series, and
– any publisher IEDs claiming conformance to any existing version of the IEC 61850 series
NOTE There is no way for subscriber IEDs to identify the edition/revision of publisher IEDs from received GOOSE
and SV messages. However, no specific implementation is required on the subscriber IED regarding the edition
/revision of the publisher IED.
6 GOOSE and SV messages validation use cases
6.1 Use case 1: Upgrade of system communication configuration using SCD or SED
without updating all subscriber and/or publisher IEDs
It may happen when:
– Last minute change has been applied in part of the system configuration
– Upgraded SCD has not been successfully applied by ICTs associated to the IEDs which
configuration (publisher or subscriber) has been modified during the upgrade
6.2 Use case 2: Extension of substation with new bays
It may happen when:
– Adding new publisher IED to an existing subscriber
– Changing existing data set
• Adding new data member to GOOSE and SV data set
6.3 Use case 3: Replacement of an IED with same configuration as previous one
It may happen when:
– IED name is not changed
6.4 Use case 4: Wrong configuration loaded into an IED
It may happen when:
– Old configuration version is used in an IED
– Configuration of another IED is used. In that case, IED may duplicate multicast telegrams
on the network. In addition, it may create IP communication problems due t
...