In certain occasions it is necessary to read and understand the communication frames that circulate between an IED and a client terminal such as a SCADA or GATEWAY. When we have absence of data, unexpected invalid quality or errors in the timestamp of data, we can make use of tools such as Wireshark to capture and analyze data flows. However, some of the descriptions we obtain are too abstract, making it difficult to identify the fields and values that could help us in the diagnosis of the problem. This is the case of the IEC 61850 reports through the MMS protocol
In this article we will deepen the understanding of the information provided by Wireshark in two scenarios: first, when reading an object of type ReportControlBlock, from which the client tool makes decisions to enable or not a report; and second, the sending of spontaneous data through the informationReport, which is undoubtedly the main object type during the monitoring phase in IED with IEC 61850.
Reading a Report Control Block
Figure 1 shows the beginning of a communication between an IED with IP address 85.16.1.21 and a SCADA system with IP 85.16.1.64. The first two frames of the communication establish the MMS communication parameters between the two entities. After that the SCADA requests a report reading with identification: IO1CFG/LLN0$BR$BRep01.
As a result of this request, IED responds with the following structure, see figure 2, which we will see in detail below.
To begin we will focus on the structure that forms the body of the response:
structure: 13 items
Data: visible-string (10) --- Identificador del reporte (RpdID)
visible-string: IO1CFG/LLN0$BR$BRep01
Data: boolean (3) --- Si está habilitado (RptEna)
boolean: False
Data: visible-string (10) --- Nombre del Dataset (DatSet)
visible-string: IO1CFG/LLN0$DSet01
Data: unsigned (6) --- Versión de configuración (ConfRev)
unsigned: 1
Data: bit-string (4) --- Campos opcionales (OptFlds)
Padding: 6
bit-string: 7c80
Data: unsigned (6) --- Tiempo de buferado (BufTm)
unsigned: 500
Data: unsigned (6) --- Número secuencia del reporte (SeqNum)
unsigned: 0
Data: bit-string (4) --- Opciones de disparo (TrgOps)
Padding: 2
bit-string: 60
Data: unsigned (6) --- Periodo de integridad (IntgPd)
unsigned: 0
Data: boolean (3) --- Interrogación general (GI)
boolean: False
Data: boolean (3) --- Purga (PurgeBuf)
boolean: False
Data: octet-string (9) --- ID última entrada (EntryID)
octet-string: 0000002100000000
Data: binary-time (12) --- Última entrada (TimeOfEntry)
binary-time: Aug 14, 2018 23:43:42.660000000 UTC
Some of the fields are of direct interpretation, for example the report identifier (RptId) or whether or not the report is enabled (RptEna). In the case of RptEna, the logic works in the opposite direction. RptEna=True tells us that the report is already enabled, that is, that it is not available to be taken by another client. However, others require a better explanation such as the optional fields (OptFlds) or the trigger options (TrgOp).
In the case of optional fields, their value must be broken down into bits. For this example, the given value is 7c80 with 6 padding bits, ie, equivalent to 0111110010000000 and excluding the 6 less significant bits you have 0111110010.
|
Position |
Parameter |
Value |
|
1 |
Not used |
0 |
|
2 |
Include sequence number |
1 |
|
3 |
Include time-stamped reporting |
1 |
|
4 |
Include transmission cause |
1 |
|
5 |
Include the name of the dataset |
1 |
|
6 |
Include object identifiers |
1 |
|
7 |
Buffer-overflow |
0 |
|
8 |
Include Entry Id |
0 |
|
9 |
Include conf-revision |
1 |
|
10 |
Skip segmentation |
0 |
For efficiency reasons, it is recommended to enable optional fields. These can be useful if we are diagnosing a communication problem or if the client node needs one of these, for example when handling Entry ID and purging buffered reports.
On the other hand, the trigger options are shown as a bit-string of value 60 with 2 padding bits. Repeating the operation, 60 is equivalent to 01100000 minus 2 bit we have 011000.
|
Position |
Parameter |
Value |
|
1 |
Not used |
0 |
|
2 |
Data exchange (Data-change) |
1 |
|
3 |
Quality change (Quality-change) |
1 |
|
4 |
Data update (Data-update) |
0 |
|
5 |
Integrity |
0 |
|
6 |
General Interrogation (GI) |
0 |
Reports are usually expected to respond to data changes (Data-change), quality (Quality-change) and general interrogation (GI), which is not the case in this examp
Interpreting an Information Report
An Information Report is the structure that comes from a report against one of the trigger conditions for which it was configured. Figure 3 presents an example of the capture of this type of structure.
The interpretation of the fields in an information report depends on the optional fields that have been enabled. To understand this, we will analyze the following frame:
MMS
unconfirmed-PDU unconfirmedService: informationReport (0) informationReport variableAccessSpecification: variableListName (1) listOfAccessResult: 11 items AccessResult: success (1) success: visible-string (10) --- Identificador del reporte (RpdID) visible-string: IO1CFG/LLN0$RP$URep0101 AccessResult: success (1) success: bit-string (4) --- Campos opcionales (OptFlds) Padding: 6 bit-string: 7e80 (de este campo se definen los siguiente)
AccessResult: success (1)
success: unsigned (6)
unsigned: 14 --- Valor de secuencia
AccessResult: success (1)
success: binary-time (12) --- Estampa de tiempo de reporte
binary-time: Aug 15, 2018 16:36:41.741000000 UTC
AccessResult: success (1)
success: visible-string (10) --- Nombre del dataset
visible-string: IO1CFG/LLN0$DSet07
AccessResult: success (1)
success: boolean (3) --- Buffer overflow
boolean: False
AccessResult: success (1)
success: unsigned (6) --- Versión de configuración
unsigned: 1
AccessResult: success (1)
success: bit-string (4)
Padding: 0
bit-string: 800000 --- Identificador de segmento
AccessResult: success (1)
success: visible-string (10) --- Identificador de objeto
visible-string: IO1ANN/IN2GGIO12$ST$Ind01
AccessResult: success (1)
success: structure (2)
structure: 3 items
Data: boolean (3) --- Valor del objeto
boolean: False
Data: bit-string (4) --- Calidad del dato
Padding: 3
bit-string: C000
Data: utc-time (17) --- Estampa de tiempo del dato
utc-time: Jan 1, 1970 00:00:00.000000000 UTC
AccessResult: success (1)
success: bit-string (4)
Padding: 2
bit-string: 40 --- Causa de transmisión
The key to the analysis is in the optional fields. You have to interpret this value and according to that you will find the following values sequentially:
- Sequence number (seqNumber)
- TimeStamp
- Name of the Dataset
- Buffer-Overflow
- Report Entry ID (EntryId)
- Configuration Review (ConfRev)
For this case, the fields that require additional interpretation would be the Quality and Cause of transmission. For quality we have C000 with 3 fill bits, i.e.: 1100000000000. The following table will help us interpret its value:
|
Position |
Parameter |
Value |
|
1 |
Valid(Good | Invalid | Reserved | Questionable) |
1 |
|
2 |
1 |
|
|
3 |
Overflow (Overflow) |
0 |
|
4 |
Out of range (OutOfRange) |
0 |
|
5 |
Bad Reference (BadReference) |
0 |
|
6 |
Oscillatory (Oscillatory) |
0 |
|
7 |
Failure (Failure) |
0 |
|
8 |
Old data (Old data) |
0 |
|
9 |
Inconsistent (Inconsistent) |
0 |
|
10 |
Imprecise (Inaccurate) |
0 |
In this case, the quality of the data is questionable, indicated by the value 11 of the first two data bits. Finally, the transmission cause is 40 with 2 fill bits, i.e.: 010000. Using the same table as TrgOpts we have:
|
Position |
Parameter |
Value |
|
1 |
Not used |
0 |
|
2 |
Data exchange (Data-change) |
1 |
|
3 |
Quality change (Quality-change) |
0 |
|
4 |
Data update (Data-update) |
0 |
|
5 |
Integrity |
0 |
|
6 |
General Interrogation (GI) |
0 |
In the following link we include online tools that facilitate the interpretation of these fields.
Artículo redactado por: PhD. Iván Dario Claros, Gerente R&D – Axon Group
