This tissue is proposing a revision to the GOOSE state machine defined in IEC 61850-8-1, and an addition of the Sampled Value state machine to IEC 61850-9-2, which is not currently defined anywhere within the standard (Unlike, reports, logs, GOOSE, and MMS control services.
This TISSUE has two components:
1. GOOSE/SMV Validation
Add a minimum set of criteria that is to be checked to validate the GOOSE/SMV message, which provides a consistent means to validate/subscribe to GOOSE/SMV. For example, it would help avoid subscribing to inadvertently duplicated GOOSE/SMV messages, and help augment the cyber security related checks defined in IEC 62351.
The resolution should provide a consistent set of checks/criteria that must be fulfilled to deem the GOOSE/SMV subscription to be "valid". Some IEDs may check additional criteria, but the standard should define the minimum set of criteria that is to be checked. This TISSUE is not proposing the specific criteria that is to be checked, but it is requesting the discussion to identify the mandatory set of criteria to deem a GOOSE/SMV message to be "valid".
2. GOOSE/SMV Activation
Similarly to the "valid/invalid" subscriptions, there should be a minimum set of criteria to determine if the GOOSE/SMV subscription is active/inactive, which should provide a consistent behaviour of LGOS/LSVS. The current standard does not define the requirements to differentiate between "active" and "active" GOOSE/SMV subscriptions, therefore we are witnessing inconsistent behaviours of the LGOS/LSVS.st.stVal, which is the only mandatory DO of these LN's.
Proposal
This TISSUE proposes to develop a more sophisticated means of validating GOOSE/SMV subscriptions, as well as reporting the active/inactive state of each subscription. See attached the proposed state diagrams with generalized checking criteria for each state (valid/active).
This is also applicable to IEC 61850-9-2 (Lack of SMV State Machine) and IEC 61850-7-4 (LGOS/LSVS.st - clarify meaning of .ST DO).
See other related TISSUEs:
1503/1609: Is it mandatory to check confRev for GOOSE subscriber? And if yes, should it be a standardized rule?
1505: Requirement of Detection of duplicate GOOSE message by a subscriber IED
Discussion
Created
Status
04 Jun 19
Future Improvement
7-4 Ed2.1 under circulation has clearly defined the active subscription:
"If true, the subscription is active and valid message forwarded to application, otherwise it is inactive or messages are not forwarded to application. ConfRevNum and RxConfRevNum can deliver further iagnostic information. "
The application is the using the subscribed data vs. the application is not using the subscribed data.
A new Ad'hoc TF has been created for further discussing the subscriber behavior and diagnistic functionality.