Abstract Communication Service Interface (ACSI)

The basic services that are used to mediate between the outside world and the real wind power plant device are referred to as Abstract Communication Service Interface (ACSI). The basics of these services described in details in IEC 61850-7-1 and IEC 61850-7-2. The figure below illustrates the various components of the ACSI models.

Time Synchronisation

Information exchange model for wind power plants (IEC 61400-25-1)

A physical device with a communication interface is represented on a server as a logical device. The server is accessible over the network making it possible to accept client system connections and support services to the client following authentication.

The logical device(s) contain(s) logical nodes that represent the various components and functionality of the logical device. Logical nodes can respond to control inputs, provide reports configured by the client, and contain logs which can be queried by the client. The logical nodes contain data objects which can be written to or read. Read and write operations are done through the services provided at the level of the logical node and downwards. The client can create data sets of an arbitrary number of data objects and read or write to these data objects as a group as well as being as being able to read and write individually named data values.

Services are provided which enables a client to create, delete, list, read or write to data sets. This arbitrary grouping lets the client system define collections of data attributes that are commonly needed and retrieve them with a single read operation using a single name referring to the data set.

In the ACSI models, the information that gets reported or logged is represented by data sets. This permit specifying the rules for reporting and logging to be defined in a more compact manner applying to a group of data.

2.1.3.1 Reporting

The reporting services must make it possible to subscribe to spontaneous data reports on specific conditions for data values. Conditions such as change of value or change of attribute values will trigger a preconfigured reporting subscription and start dispatching the values. It should also be possible to cancel a report subscription.

1. In the reporting mechanism, the server must make available the data for the client to read and write. As mentioned above the data subject to retrieval can be configured by the client as a group of data objects named data sets. Since it is not common practice in client server architecture for a server to contact a client offering data, the server should buffer the values to deliver it later to the client, whenever a client request is made. Otherwise the server has to contact the client and deliver the data to it, which turn upside down the client server architecture.

2. In order to achieve buffering mechanism so that the server does not have to notify the client for the available new data, some sort of a server side session must be implemented for the reporting interaction between client and server.

The server must have an internal state making it possible to keep track of which step in the reporting process it is in and which data have been sent and which is still in the buffer. However, the standard also specifies that it must be possible to configure the reporting mechanism such that data is not buffered in case of a connection interruption, meaning that the client only can access the data available at the time it makes its service request.

The reporting mechanism is controlled by an REPORT-CONTROL class which can be configured through its attributes. The REPORT-CONTROL references an instance of a data set which groups the data in interest. The attributes of an REPORT-CONTROL instance used to configure the reporting can be accessed through specific services made available for the REPORT-CONTROL class. The details of the REPORT-CONTROL class are defined in 14.2 of IEC 61850-7-2.

Buffered Reporting

A client process can configure the behavior of buffered reporting through an instance of a BUFFERED-REPORT-CONTROL-BLOCK (BRCB). This instance is created through the AddSubscription service made available to client processes. A BRCB instance has a set of attributes used to control the behavior of the reporting mechanism. It also has a DATA-SET reference for which the reporting is applied to. Whenever a BRCB instance is enabled an Event-Monitor should monitor all the data instances referenced by the report-control-block DATA-SET. The Event-Monitor must send event notification instances to the Report-Handler which will further delegate it to the respecting BRCB instance.

Whenever the BRCB instance receives an event notification it will generate a report and push it onto the report buffer stack, making it available for client retrieval. In case of a client thread blocked on a buffer event, the BRCB instance must notify the client thread to pick up the generated report. The BRCB should generate a report even if at that moment there is no client actively waiting for a report. The immediate delivery of reports to clients requires a fine grained synchronization mechanism which will be discussed later in this section.

Un-Buffered Reporting

A client process can configure the behavior of un-buffered reporting through an instance of an UNBUFFERED-REPORT-CONTROL-BLOCK (URCB). Un-Buffered reporting is similar to Buffered reporting with one important exception. As the name implies, in Un-Buffered reporting the generated reports is not buffered on a report buffer.

If a previously generated report is not picked up by a client, this previous report will be swapped with the new report. That is, the order of sequence or the loss of reports is not considered by the server. A report can be retrieved by the client in the period until another report is generated, otherwise it will be lost.

Report Handler

A report handler object should be able to maintain all the subscribed REPORT-CONTROL-BLOCK instances together with the report buffers assigned to each client process. The dispatching of report requests should also be controlled by the report handler. It must be possible to enable a mechanism so that client processes can wait for a specific amount of time to retrieve a generated report. Immediate delivery of generated reports will be possible through such a mechanism which is required for an event driven data retrieval model.

In order to have a wait/block mechanism for requesting clients, the report handler must maintain a thread pool with reusable threads in order to make the process fast and efficient. Creating a new thread for each report request will use unnecessary amount of resources on the server side.

Whenever a client requests for a report, the report handler must dispatch an available thread to the client and make the assigned thread block on an event. By this, the report request service will not return immediately but instead wait until it is released and thereby return the response object to the client. Whenever a report is issued the report handler will notify the awaiting thread and release the blocked request so that it will continue its execution and thereby return available reports to the client if any. The wait/block mechanism must have a suitable wait-time and release the block so that the underlying service connection does not timeout. The two different cases in wait/block mechanism are illustrated in the figure below.

Figure 6 Wait/block mechanism

Each client is responsible of reconnecting to request and wait for new reports after a report request service call has returned. The wait/block mechanism is a polling mechanism extended with timeouts to achieve a similar behavior as in a connection oriented interrogation. It is not possible to establish a pure connection oriented interrogation when using communication technologies such as web services.

Event Monitor

Monitoring events is an important part of the reporting mechanism. It should be possible to monitor the data instances referenced by RCB instances (through DATA-SET) configured for each client. That is, only the data referenced by reporting will be monitored. Whenever the state of a data instance alters, the event monitor must send an event notification to the report handler. The event notification must contain a reference to the subject data together with an indicator of the type of state change.

After notified by the event monitor, the report handler must identify the RCB(s) referencing to that particular data and generate a report for each of the RCB. Depending on the RCB the generated reports will be pushed to the report buffer or delivered directly to an awaiting client.

Report Request

Reporting Response

Time out

Report Request

Reporting Response

Time out

Report Notification

t t

2.1.3.2 Logging

Logging like reports can be initiated upon the client’s request. Like reports the data can be logged on the same criteria. (Change of value etc.) But in addition to this, updates also must be logged.

The client must at any time be able to get a log stream for a given interval. Due to the data storage amount it must be assumed that this time storage is limited concerning the log available for the WPP itself. Reports reflect current data while logging reflect longer term data, and system status.