particular, Figure
2
gives the details about the data type structure.
To allow the Web User to access the elements of this data model, a syntax had to be
defined to univocally identify each IEC 61850 element; it was assumed to adopt the IEC
61850 conventions as much as possible. For each element present in the IEC 61850 data
model, the relevant identifier from the Web User point of view is defined as a sequence
of names separated by “/”. The sequence of names is defined according to the same
hierarchical order shown by Figures
1
and
2
. Thus, the identifier must first foresee the
attribute name of the IED. Then, the value of the attribute inst of the Logical Device
contained in the IED is used after the IED attribute name. In Section
3
, it was noted that
the IEC 61850 standard identifies each Logical Node by a particular concatenation of three
attributes: prefix, lnClass, inst; for this reason, it was assumed that this concatenation is
used after the LD identifier. As Data Objects, Structured Data Objects, Basic Data Attributes,
and Enumeration are univocally identified by the attribute name according to the IEC 61850
standard, the value of this attribute is used in the identifier according to the hierarchical
order shown by Figures
1
and
2
.
On the basis of the syntax just described and considering the example of the IEC 61850
data model depicted by Figure
3
, the identifier of the BDA with the name = “f” becomes
“BCU1M19/C1/LBAYMMXU1/A/phsB/cVal/mag/f”; the identifier of the BDA with the
name = “db” is “BCU1M19/C1/LBAYMMXU1/A/phsB/db”.
4.2. Web User Registration and Authentication
Use of the IEC 61850 Web Platform by a Web User may occur only after his registration.
If the user is not yet registered in the system, he must issue a suitable POST request to a
specific Web Service Interface, the body of which must contain, in JSON format, the credentials
(username and password) with which the user intends to register. If the registration procedure
succeeds, the Web User will receive a POST response, again in JSON, indicating that the
operation was completed successfully. If registration procedure fails (e.g., if the user is already
present in the system), the POST response will specify the failure reason.
Before the registered Web User may proceed to request synchronous services, he
must authenticate himself to the platform. The user will send a POST request to another
specific Web Service Interface relevant to the authentication service, specifying his personal
credentials used during the registration. If the authentication request succeeds, the Web
User will receive a response containing a signed token to be used in each of the next Web
Service synchronous requests issued to the IEC 61850 Web Platform.
4.3. Access to an IEC61850 Server
The main aim of the IEC 61850 Web Platform is to allow the access to the IEC 61850
Server from the web. Access means that the Web User may request to retrieve and/or to
update information maintained by a particular IEC 61850 Server. To achieve this goal, the
Web User must pass to the platform the information about the IEC 61850 Server he desires
to access; this must be realized only one time, after registration and authentication, before
the data exchanges between Web User and the server can occur. A POST request must be
issued at a particular Web Service Interface, mainly including the IP address of the remote
machine hosting the IEC 61850 Server and the port on which the server is listening.
In Section
2
, it was noted that each IEC 61850 Server holds a particular file (i.e., the
ICD file) containing the SCL description of the data model maintained by the server. This
Sensors
2022
,
22
, 2475
8 of 17
description is needed by the IEC 61850 Web Platform to accomplish some services, as
explained in the following subsections. For this reason, on receipt of the Web User’s
request, the Middleware connects to the server specified by the Web User in order to
retrieve the relevant ICD file and store it in the local SCL repository shown by Figure
4
.
This operation is not performed if the Middleware realizes that the same server is used
by other Web Users and the relevant ICD file has been already retrieved and stored in the
local SCL repository; in this case the same ICD file is associated to more Web Users. On
the completion of this operation, the IEC 61850 Web Platform will respond with a POST
response, pointing out the success of the previous Web User request.
A disconnection procedure has been foreseen through a specific POST request issued
by the Web User, when the data exchanges with a specific IEC 61850 Server end. All the
local resources allocated to maintain the SCL file descriptions of the IEC 61850 Server data
model accessed by the Web User are released if not used by other users.
4.4. Publication of Data Types
The main requirements in an interoperable data exchange include the capability to prop-
erly decode each piece of information received from the counterpart. To enable each value
received to be properly decoded by the receiving entity, the relevant data type must be known.
Knowledge of the data type to which each variable exchanged belongs is of paramount im-
portance. The Web User must be able to encode/decode each piece of information exchanged
with the IEC 61850 Server through the IEC 61850 Web Platform, and this can be achieved only
on the basis of the knowledge of the data types involved in the information exchange. This
means that the data type descriptions of the data maintained in the IEC 61850 Server must be
known to the Web User, or at least the subset of data of his interest.
For this reason, a particular service was defined that allows a Web User to retrieve
the description of the entire set (or a subset) of data types maintained by each IEC 61850
Server that is relevant to the information the Web User needs to retrieve from the IEC 61850
Server. A suitable POST request can be issued to a specific Web Service Interface, through
which the Web User will specify the data types requested and the Broker to be used for
the publication of these data types. The requested data type is described using the syntax
introduced in Section
4.1
. For each POST request received, the IEC 61850 Web Platform
will explore the Local SCL Repository in order to find the information related to the IEC
61850 data types requested by the user. A JSON frame is built containing the description of
these data types; this frame will be published through MQTT message by the requested
Broker, on a particular topic which is passed to the Web User through the POST response.
Subscription to this topic by the Web User allows him to receive the requested data type
description though a JSON payload inside the MQTT frame received.
Figure
5
shows an example of the above description; in particular, Figure
5
shows the
steps that enable the Web User to retrieve the description of the data type of the BDA with
the attribute name = f” shown by Figure
3
. According to the syntax described in Section
4.1
,
this BDA is identified by the string “BCU1M19/C1/LBAYMMXU1/A/phsB/cVal/mag/f”.
These steps are represented inside numbered circles, as shown in Figure
5
; the numbers
are assigned according to the temporal sequence of the steps. In the first step, the Web
User submits a POST request including the identifier of the BDA whose data type he is
interested in and the details about the Broker to be used for the publication (this last piece
of information is not shown in Figure
5
due to the lack of space). In order to accomplish the
user’s request, the Middleware will analyze the SCL data model description maintained
by the Local SCL Repository (step 2), looking for the SCL description of the BDA in the
DataTypeTemplates section of the SCL file associated with the Web User. Figure
5
shows
the piece of the SCL DataTypeTemplates section relevant to the requested BDA, inside the
callout. The SCL description of this data type is translated into JSON format, thus obtaining
the payload shown in Figure
5
close to the step number 3. This payload is published to the
Broken chosen by the Web User. The IEC 61850 Web Platform will send the topic identifier
as a POST response to the Web User (step 4). In step 5, the Web User will subscribe to this
Sensors
2022
,
22
, 2475
9 of 17
topic on the specified Broker. Subscription will allow the Web User to receive an MQTT
frame containing the requested BDA data type in JSON format (step 6).
|
