BSI Standards PublicationWind turbines Part 25-3: Communications for monitoring and control of wind power plants — Information exchange models... NORME EUROPÉENNE English Version Wind tu
General
The information exchange models for operational functions described in Clause 7 are as follows:
• monitoring, reporting and logging model
Functional constraints of the ACSI services are specified in Annex B.
Association and authorisation model
The association and authorization model aims to ensure secure information exchange between a client and a server by facilitating client authentication and regulating access to server functions This conceptual mechanism is illustrated in Figure 2.
Figure 2 – Association and authorisation model (conceptual)
The requirements to be fulfilled by an association between a client and a server are as follows:
– authentication: determining the identity of the users/client,
– authorisation and access control: ensure that the entity has the proper access rights (a minimum is to provide a user name and a password),
– integrity: messages and the computer infrastructure are protected against unauthorised modification or destruction,
IEC client server initiate remote authorisation check requested authorisation association request wait for confirmation process requests from client association opened (or denied) operational information exchange (Get, Set,
Control, ) close association operational information close association
secure association ready to receive requests granted no need to communicate local authorisation
– confidentiality: objects of the wind power plant information model are protected and only disclosed to appropriate users/clients,
– non-repudiation: preventing a user/client involved in a data exchange from denying that it participated in the exchange,
– prevention of denial of device: preventing a client/server from blocking access to authorised users
The authorization model's true services are defined by the specific mappings outlined in IEC 61400-25-4 Depending on the chosen mapping, the level of security and the supported services may vary significantly.
Control model
General
The control model facilitates information exchange for operating commands and is applicable solely to control objects, specifically data object instances of a controllable common data class (such as SPC or INC) where the DataAttribute "ctlModel" is not designated as "status-only." Primarily, the control model is utilized to modify a device's status, such as starting or stopping a turbine, or to adjust the value of a set point or parameter The conceptual mechanism of the control model is illustrated in Figure 3.
NOTE The control model with its state transitions and services is described in more detail in IEC 61850-7-2:2010 (Clause 20)
Operate [TimeActivatedOperate] enhanced security; optional
The SBO (Supervisory Control) system allows for optional initiation of control commands issued by the client server It includes a validity check to reserve access to the control object for the requesting client Once access is granted, the system processes the control command, which involves checking validity, activating a timer, and waiting for the timer to expire before proceeding Additionally, the system supervises any requested status or value changes to ensure accurate monitoring and control.
IEC 61850-7-2:2010 describes different models for the control object:
– direct control or select before operate (SBO),
– normal security or enhanced security, and as an extension
– operate or time activated operate
The value of the control object’s dataAttribute “ctlModel” determines which of the supported models can be applied to the control object
Tracking of the control services is beyond the scope of this standard.
Direct control / Select before operate (SBO)
With direct control, the control object shall not be selected before sending the “Operate” (or
With SBO, the control object shall be selected before sending the “Operate” (or
Upon receiving a "SelectWithValue" request, the server validates the command and responds positively while initiating a deselect timer Access to the control object is then limited to the requesting client and the specified action The control object will be deselected either when the deselect timer expires or if the client issues a "Cancel" command.
Operate / TimeActivatedOperate
Within one control sequence, either Operate OR TimeActivatedOperate shall be used
On receipt of an “Operate” request, the server checks the validity of the command, issues a positive “Operate” response and starts to process the requested action
The “TimeActivatedOperate” command contains in addition a parameter “operTm” that holds an absolute time at which the command shall be executed On receipt of a
The "TimeActivatedOperate" request prompts the server to verify the command's validity, activate a timer, and respond positively Once the designated time arrives, the server automatically processes the command and issues a "TimeActivatedOperate" termination.
Normal security / Enhanced security
In systems with normal security, the Report service can optionally notify clients of any requested status or value changes However, when enhanced security is in place, the server actively monitors these changes Once a status or value change occurs, the server reports the updated status (stVal) to the client through the Report service and subsequently sends a "CommandTermination" request.
Monitoring, reporting and logging model
The conceptual information exchange models for monitoring, reporting and logging are shown in Figure 4 The models comprise three independent information retrieval methods:
1) Values can be retrieved on demand by a client (upper part of the figure) This is commonly known as Get or Read; the response will be transmitted immediately
Values can be communicated to the client using a publisher/subscriber reporting model, where the server is set up to send values either spontaneously or at regular intervals The client receives reports when specific trigger conditions are met on the server This model can buffer events during communication link failures, ensuring that all buffered events are transmitted sequentially once the connection is restored However, for unbuffered reports, the delivery of events is not guaranteed if the communication link fails.
Values can be logged directly on the device, ensuring that events are buffered and delivered in the correct sequence The logging model supports multiple data sources, which can be independently configured through Data Sets Clients have the ability to query the log for entries within a specific time range or retrieve all entries following a particular entry.
The reporting and logging models consist of three key components: a Data Set class (DS) for referencing data groups to be logged or reported, a Control Block class to manage the dynamic behavior of information logging or reporting, and a Log class that defines the storage of logs.
Figure 4 – Monitoring, reporting and logging model (conceptual)
The retrieval methods have the characteristics given in Table 2
The IEC client-server model initiates and enables subscriptions to receive and monitor values for changes periodically It produces events and sends values based on changes or events, while also allowing for the reception and local processing or display of these values Subscriptions can be disabled or removed as needed Additionally, values can be sent periodically or on demand, with the ability to request, receive, and locally process time-series data through logging and querying.
Table 2 – Comparison of the information retrieval methods
Retrieval method Time-critical information exchange
Can lose changes (of sequence)
Multiple clients to receive information
Last change of data stored by
Typical client (but not exclusively)
Data on demand NO YES YES – Browser
Unbuffered reporting YES YES YES – Real-time GUI
Buffered reporting YES NO YES Server Data concentrator
Logging NO NO YES Client Plant operation, engineering stations
Each retrieval method possesses unique characteristics, and no single approach can fulfill all application needs Therefore, during the system design phase, it is essential for the designer to evaluate the requirements and compare them with the methods available in devices that comply with the IEC 61400-25 series.
General
The management function models outlined in Clause 8 are essential for establishing and maintaining a system These functions encompass the setting and modification of configuration data, as well as the retrieval of configuration information from the system.
• user management/access security model,
Functional constraints of the ACSI services are specified in Annex B.
User management/access security model
Apart from the service requirements given in 7.2, these functions are an implementation- specific issue.
Setup model
Apart from the service requirements given in 7.2, these functions are an implementation- specific issue.
Time synchronisation model
The synchronisation of the various clocks in a system is a matter of the specific mapping selected and is specified in IEC 61400-25-4.
Diagnostic (self-monitoring) model
The diagnostic or self-monitoring functions are designed to assess the operational status of a device, indicating whether it is fully operational, partially operational, or non-operational This diagnostic information is specified in the logical node LPHD as outlined in IEC 61400-25-2.
9 The ACSI for wind power plant information models
General
The information exchange models outlined in Clauses 7 and 8 provide a comprehensive overview of the necessary models for compliance with the IEC 61400-25 series Additionally, Clause 9 offers a detailed description of all required services.
Figure 5 illustrates the fundamental information exchange models, highlighting the key components of ACSI services This figure serves to narrate how a typical device engages with external environments through these services.
Figure 5 – Conceptual information exchange model for a wind power plant
The specification in Clause 9 provides a high level definition of services The normative definition of the details of the ACSI models and services are defined in IEC 61850-7-2.
Services of association and authorisation
The application association model consists of provisions on how the communication between the various types of devices is achieved The model comprises:
• class definitions of associations, and
• access control concepts (how to restrict access to instances in a server)
The application association model defines the services provided for managing associations between client and server (two-party application association)
NOTE The details of an application association model are defined in the SCSMs
Report control block values on change, event, periodic
Subscribe values on change, event, periodic
Report (values on change, event, periodic) bidirectional information exchange unidirectional information exchange
Logical node Data data flow
The access control model enables the restriction of a client's access to specific class instances, their attributes, and ACSI services associated with those instances on a designated server.
The services for two-party-application-association class are listed in Table D.1
The details of the two-party-application-association class services shall be as defined in Clause 8 of IEC 61850-7-2:2010.
Services of GenServerClass
A server reflects the external behavior of a device, allowing a client to access it To obtain a list of ObjectReferences for all logical devices accessible to the requesting client, the client should utilize the GetServerDirectory service, as detailed in Table D.3.
Clause 7 of IEC 61850-7-2:2010 outlines the specifics of the GenServerClass services, emphasizing that "logical-device" is the sole acceptable value for the ObjectClass parameter within this standard.
Services of GenLogicalDeviceClass
A logical device, such as a wind turbine controller, consists of various logical nodes, including the rotor, transmission, and generator Users can explore the logical device to access the ObjectReferences for all its contained logical nodes, as detailed in Table D.3.
The details of the GenLogicalDeviceClass services shall be as defined in Clause 9 of IEC 61850-7-2:2010.
Services of GenLogicalNodeClass
A logical node (for example, a transmission) is a collection of data objects (for example, transmission gear temperature)
The GetLogicalNodeDirectory service allows users to browse logical nodes and retrieve the names of all instances for a specified ACSIClass According to the IEC 61400-25 series, valid ACSIClass values are limited to data object, DATA-SET, BRCB, URCB, LCB, and LOG.
The GetAllDataValues service allows clients to access all data attribute references and their corresponding values, which share the same FunctionalConstraint, for all data objects that are made visible and accessible by the referenced logical node.
The details of the GenLogicalNodeClass services shall be as defined in Clause 10 of IEC 61850-7-2:2010.
Services of GenDataObjectClass
A data object (for example, status of a rotor) is a collection of data attributes (for example, actual status value, quality, timestamp)
The attribute values of data objects (i.e., its data attributes) can be set or retrieved by using the services GetDataValues or SetDataValues as shown in Table D.3
A client shall use the GetDataDirectory service to retrieve the list of all data attribute names of the referenced data object
A client shall use the GetDataDefinition service to retrieve the complete list of all data attribute definitions of the referenced data object
The details of the GenDataObjectClass services shall be as defined in Clause 11 of IEC 61850-7-2:2010
EXAMPLE GetDataValues “WindPowerPlant12/WGEN.W.phsA.cVal.mag.f[MX]” returns the floating point value of the current value.
Services of DataSetClass
A data set consists of an organized collection of ObjectReferences to data objects (FCDs) and/or data attributes (FCDAs) The contents of these data sets can be accessed or modified through specific services Additionally, data set instances are utilized by report control blocks to determine which data should be monitored and reported based on defined criteria.
The details of the DataSetClass services shall be as defined in Clause 13 of IEC 61850-7-2:2010.
Services of ReportControlBlockClass
A report control block enables the spontaneous reporting of data values based on specific criteria, such as changes in value or quality information, or at regular intervals Its behavior is influenced by attribute values, including the ability to enable or disable reporting and the use of sequence numbers Additionally, the report control block is linked to a data set instance, and its attributes can be modified or accessed through designated services.
The BRCB (Buffered-Report-Control-Block) not only facilitates reporting but also ensures that events are not lost during temporary communication interruptions by utilizing a sequence-of-events In contrast, the URCB (Unbuffered-Report-Control-Block) does not offer this protection, resulting in event loss when communication is disrupted.
The details of the ReportControlBlockClass services shall be as defined in 17.2 of IEC 61850-7-2:2010
The fundamental reporting mechanism, illustrated in Figure 6, involves the configuration of report control blocks for both buffered and unbuffered reporting To initiate reporting, the enable buffered RCB attribute must be set to TRUE, while setting it to FALSE will halt the reporting process These reporting methods are straightforward and offer an efficient means of transmitting changes in real-time.
Figure 6 – Buffered report control block – conceptual
Services of LogControlBlockClass and LogClass
A log control block is essential for logging data values based on specific criteria, such as changes in value, quality information, counter updates, or periodic intervals Its behavior is influenced by attributes like enabling or disabling logging Additionally, the log control block is linked to a data set instance, and its attributes can be configured or accessed through designated services.
The log provides the query services to retrieve data values The attributes of an instance of a log can be retrieved by using the services shown in Table D.3
The services QueryLogByTime and QueryLogAfter, as specified in IEC 61850-7-2:2010, will offer a filter parameter that allows users to select one or more functionally constrained data (FCD) or functionally constrained data attributes (FCDA) from a data object for querying.
The details of the LogControlBlockClass and LogClass services shall be as defined in 17.3 of IEC 61850-7-2:2010.
The DataFilter according to Table 3 shall be added to the QueryLogByTime and QueryLogAfter requests
The parameter DataFilter shall specify the functionally constrained data (FCD) or functionally constrained data attribute (FCDA) of a DATA
If the data filter parameter is omitted, no filtering will occur The selection of data relies solely on the RangeStartTime parameter in conjunction with either the RangeStopTime or Entry parameters.
The IEC client-server model initiates and establishes a subscription, enabling the configuration of buffered Report Control Blocks (RCB) It monitors the values of data set members and reports these values while waiting for incoming reports In the event of an association loss, the system continues to monitor and buffer the values of data set members, ensuring that both buffered and new reports are sent once the association is restored Finally, the subscription and buffered RCB can be disabled, along with the sequence-of-events (SoE) functionality.
The ListOfLogEntries parameter in the QueryLogByTime and QueryLogAfter responses includes log entries that are filtered by the DataFilter and fall within the specified time range defined by the RangeStartTime and RangeStopTime parameters of the service request.
NOTE The filter parameter allows to reduce the amount of information to be returned considerably
Figure 7 illustrates a log alongside three log control blocks Initially, it is essential to connect with the server and configure the log control blocks Once these blocks are enabled, the server association can be terminated Log entries are recorded in the log as they are received, maintaining a time-sequenced order that facilitates the retrieval of a sequence-of-events (SoE) list.
Figure 7 – Log control block – conceptual
Logging can be activated at any time, ensuring that log entries are recorded regardless of active client associations Various log control blocks facilitate the management of information storage from distinct data sets, with each block operating independently of the others.
Services of ControlClass
A control class provides the mechanism to control functions and real devices represented by a server
The control class provides the services shown in Table D.3
The details of the ControlClass services shall be as defined in 20.5 of IEC 61850-7-2:2010
IEC client server initiate logging of a single LCB establish and enable a LCB configure LCB enable LCB query log entries get log status values
ListOfLogEntries disable a LCB disable LCB disable a LCB sequence-of-events (SoE)
Set LCB Data query log by entry/time Set log entry
Data Data reference reference value reference association opened
Examples of reporting and logging services
Reporting example
Figure A.1 illustrates an example of a report service, where the reported values are sourced from the members of a DataSet named "MyDS." This DataSet includes references to both data attributes and data objects, with the position of each member clearly defined and recognized by both the client and server.
The report only includes values that have changed since the last update, with each new value change prompting a new report To indicate which data corresponds to the changed values, an "inclusion bitstring" is utilized, containing a bit for each member of the DataSet For instance, if the first member's value has changed, the first bit is set to TRUE, allowing the receiver to identify the data source, such as "WindPowerPlant12/WGEN.W.phsA.cVal.mag.f," based on its position in the bitstring.
The full object identifier “WindPowerPlant12/WGEN.W.phsA.cVal.mag.f” may optionally be transmitted – but this is not required
Figure A.1 – Mapping of information models to data sets for reporting (example)
The report may optionally contain also parameters such as:
– Report identifier (RpdID) – handle given by the client,
– Sequence number – for detection of lost segments,
– SubSequence number – if values do not fit into one report,
– Cause for reporting (reason code) – data change, quality change, etc
Subclause 17.2 of IEC 61850-7-2:2010 contains additional examples on reporting.
Logging example
An example of logging is shown in Figure A.2
WGEN W phsA cVal mag f ang i
WindPowerPlant12/WGEN.W.phsA.cVal.mag.f WindPowerPlant12/WGEN.W.phsA.cVal.mag.i WindPowerPlant12/WGEN.W.phsA.cVal.ang.f WindPowerPlant12/WGEN.W.phsA.cVal.ang.i
Log entries are generated from instances referenced by a DataSet, which serves as the source for both reporting and logging Any change in these values prompts the creation of a log entry, which includes the timestamp of the entry, the object reference of the data object or attribute, and the current value, typically represented as a floating-point number.
The log has additional attributes:
– OldEntrTm (timestamp of the oldest entry),
– NewEntrTm (timestamp of the newest entry),
– OldEntr (identifier of the oldest entry),
– NewEntr (identifier of the newest entry)
These attributes can be read
The Query Log service allows retrieval of log entries identified by a time range (between time
To retrieve specific entries from the query log, you can use either a time range or a combination of a timestamp and an entry ID, as the entry ID is necessary to distinguish between multiple entries that may share the same timestamp The response from the query log will provide the requested entries accordingly.
Subclause 17.3 of IEC 61850-7-2:2010 contains additional examples on logging
WGEN W phsA cVal mag f ang i
WindPowerPlant12/WGEN.W.phsA.cVal.mag.f WindPowerPlant12/WGEN.W.phsA.cVal.mag.i WindPowerPlant12/WGEN.W.phsA.cVal.ang.f WindPowerPlant12/WGEN.W.phsA.cVal.ang.i
Query log WindPowerPlant12/WGEN.W.phsA.cVal.mag.f
WindPowerPlant12/WGEN.W.phsA.cVal.ang.f
WindPowerPlant12/WGEN.W.phsA.cVal.ang.f
WindPowerPlant12/WGEN.W.phsA.cVal.ang.f
WindPowerPlant12/WGEN.W.phsA.cVal.ang.f
Relationship between ACSI services and functional constraints
The functional constraint (FC) serves two purposes:
This article aims to define the services applicable to specific DataAttributes, as outlined in Table B.1 It also discusses the reduction or filtering of data values in certain services, such as the GetDataValues service, which can return all DataAttributes for a specific Data or Logical Node By using the FC parameter in the service request, such as MX, users can request only the DataAttributes with FC=MX It is important to note that only FCs from IEC 61400-25-2 CDCs and those inherited from IEC 61850-7-3 are taken into account.
Table B.1 – Relationship between ACSI Services and Functional Constraints
GetAllDataValues The service is applicable with optional FC: all except SE
GetDataValues The service is applicable with FC: all except SE
SetDataValues The service is applicable with FC:
DC, CF, SV, BL, SP
GetDataSetValues The service should be applied only to those dataset elements with FC: all except SE
SetDataSetValues The service should be applied only to those datasets elements with FC:
DC, CF, SV, BL, SP
CreateDataSet The DataSetReference has no FC associated but the elements that build it can be of any FC
Report A report can include elements of FC: all except SE, see Note 1
QueryLogByTime A LogEntry can include elements of FC: all except SE, see Note 2
QueryLogAfter A LogEntry can include elements of any FC: all except SE, see Note 2
NOTE 1 Only the changes in the value of the elements defined in IEC 61400-25-2 with the TrgOp
“dchg”, “qchg”, “dupd” will generate events to send in the reports
NOTE 2 Only the changes in the value of the elements defined in IEC 61400-25-2 with the TrgOp
“dchg”, “qchg”, “dupd” will generate events to be stored in the LOG
Relationship between ACSI defined in
In wind power plant automation, the requirements differ slightly from those in substation automation systems As a result, certain ACSI classes specified in IEC 61850-7-2, which offer specific functionalities, are not necessary in the IEC 61400-25 series.
The following classes do not appear in the wind power plant:
– Files: the IEC 61400-25 series will not specify how the file interchange, if needed, will be performed
The following control blocks are not used in IEC 61400-25-3:
SGCB, or Setting Group Control Block, utilizes the functional constraint (FC) for all system settings, indicating that the server will not have multiple preconfigured setting groups.
– GoCB: GOOSE control block Control block of events of high priority between protection device inside the substation
– MSVCB: Multicast sampled values control block
– USVCB: Unicast sampled values control block
The ACSI, as illustrated in Figure 3 of IEC 61850-7-2:2010, outlines the interconnections among various components within the power utility automation sector Additionally, Figure C.1 presents the relationships defined in IEC 61400-25-3.
Figure C.1 – Conceptual service model of the ACSI
General
The following ACSI conformance statements shall be used to provide an overview and details about a device claiming conformance with ACSI:
– ACSI models conformance statement, and
– ACSI service conformance statement to specify the communication features mapped to an SCSM
The conformance statements outlined in Annex D are abstract, as they relate the ACSI models and their services to application layer models, services, and protocols Further details regarding conformance are specified in the SCSM.
The conformance requirements for several features are implicitly defined by the common data class outlined in IEC 61400-25-2 and IEC 61850-7-3, along with the compatible logical-node and data object classes specified in IEC 61400-25-2 and IEC 61850-7-4 For instance, a trigger option (TrgOp) with the value of quality change (qchg) for a DataAttribute necessitates the support of the qchg trigger option in the BRCB or URCB.
ACSI basic conformance statement
The basic conformance statement shall be as defined in Table D.1
Client/ subscriber Server/ publisher Value/ comments Client-server roles
B11 Server side (of TWO-PARTY APPLICATION-
B12 Client side (of TWO-PARTY APPLICATION-
B25 SCSM: IEC 61400-25-4:2008, Annex A (web services)
B27 SCSM: IEC 61400-25-4:2008, Annex C (ISO 9506 mms)
B29 SCSM: IEC 61400-25-4:2008, Annex E (DNP3) c 1 shall be ‘M’ if support for logical-device model has been declared.
ACSI models conformance statement
The ACSI models conformance statement shall be as defined in Table D.2
Table D.2 – ACSI models conformance statement
Client/ subscriber Server/ publisher Value/ comments
If Server side (B11) and /or Client side (B12) supported
The M16 Time O M Time source must provide the required accuracy, with specific conditions for its designation as 'M' It will be classified as 'M' if support for the logical-node model, data model, or various other models such as data-set, Substitution, Report, Log Control, or Time model is declared Additionally, it will be marked 'M' if support for Report is confirmed and if SCSM supports the dataset Furthermore, it will also be designated 'M' if a control object is supported.
ACSI service conformance statement
The ACSI service conformance statement is outlined in Table D.3, which is contingent upon the statements provided in Tables D.1 and D.2 Additionally, the conformance statement regarding time resolution and data accuracy is specified in Table D.4.
Table D.3 – ACSI service conformance statement (1 of 2)
Services Client/ subscriber Server/ publisher Comments Server (see 9.3)
S1 GetServerDirectory O cw 3 cw 3 If this service is supported by the SCSM then the service shall be mandatory
The S4 Release in conjunction with cw 4 and cw 3 requires that if these services are supported by the SCSM, the client must support either the Abort or the Release request Furthermore, it is essential for the client to comprehend the abort request sent by the server.
S29 SetURCBValues O O cw 5 If these services are supported by the SCSM, support shall be declared for at least one (BRCB or URCB)
Services Client/ subscriber Server/ publisher Comments Logging (see 9.9)
S34 GetLogStatusValues cw 3 cw 3 cw 6 If these services are supported by the SCSM, support shall be declared for at least one (QueryLogByTime or QueryLogAfter)
Services Client/ subscriber Server/ publisher Comments Time (IEC 61850-7-2:2010 6.1.2.9)
T1 Time resolution of internal clock Nearest negative power of 2 in seconds
T2 Time accuracy of internal clock T0 (10 ms)
T1 (1 ms) T2 (100 às) T3 (25 às) T4 (4 às) T5 (1 às)
T3 Supported Timestamp resolution Nearest value of
According to IEC 61850-7-2:2010, the time resolution is defined as 2**(-n) seconds It is important to note that the time accuracy of data in the Intelligent Electronic Device (IED), when retrieved from and time-stamped by other devices, is not covered by this standard and may vary from the specifications outlined in this table.
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