IEC61850 - Report Activation Problem

[andrea.ornago]

Hello everybody,
I'm working on Zenon Operator 7.50

In my test project there is one 61850 IED device (that supports URCBs).  The device has 5 report (1 to 5 reports).

1st CASE:
If, in my device configuration, I enable:
    - reports 1 to 4 -> 1 client
    - report 5 -> 2 client
Zenon IEC61850 driver is working fine (all 5 report,refer to one client, are enabled) (I have check RptEna variables and LOG file).
ConnectionState variable shows that TCP and MMS connection are OK

2nd CASE:
(same Zenon IEC61850 driver configuration)
If, in my device configuration, I try to enable more clients, Zenon IEC61850 driver can enstablish only the TCP communication (ConnectionState variable is 2, only the TCP communication is enstablished).

After I checked the LOG about the two case, why in the 2nd CASE Zenon Driver seems doesn't try to activate the report?
The communication doesn't works fine for a Zenon Driver Error? for a device Error? or both?

Attached: LOG file and Zenon IEC61850 Driver Configuration.



Thank You very much,
Andrea 

[andrea.ornago]

Maybe, Zenon doesn't try to enable the report because MMS communication must be enstablished first.... in LOG where can I find the MMS abilitation request messages?

Thanks,
Andrea

[ursulak]

In iec850 driver the variable ConnectionState value 2 means that the driver has connected the IED on TCP, so then is trying, on this TCP socket, to establish a valid MMS association. And this association must succeed before the driver will try to enable RCBs.

Maybe you take a look in Wireshark sniff what are the reactions from IED on TCP port 102. 

>2nd CASE:
>If, in my device configuration, I try to enable more clients"
I do not understand this description. What you mean with "in my device configuration, I try to enable more clients"? I suppose you are changing the SCL-file of the device? But what kind of changes are you making in SCL?

On your screenshot i see that the iec850 driver is configured with same ClientLN.iedName. This is a feature introduced by Edition 2 of the Standard and the use of this string then demands - in the SCL file you are using to update the IED:
- in section 'Communication' descriptions of TCP and OSI parameters of all 850-Clients which the IED has to accept. Else the IED will not know what is the ClientLN.iedName, as via MMS is gets only the IP and OSI addressing from the associating client, not its name as string (a severe disadvantage in the Standard).
- then in sections ReportControl.RptEnable you may use these strings to pre-assign which client shall use with instance of the RCB. 

[andrea.ornago]

Hi Ursula,
by sniffing packet with wireshark, we found a big difference between the behaviour of 2 different devices with the MMS request.
On the image dev_1 the protocol goes like Request - Response to every invokeID

On the image dev_2 we can see that zenon sends a big buffer of packets between in a very short amount of time


Can be dependent by the different initialization of 2 devices?


Thank you for your help!

Andrea

[ursulak]

sorry Andrea, but you are looking blind, so watching non-relevant things.

The difference you have highlighted - between Initiate-Response of devices: it means that DEV 2 is not supporting dynamical data sets. Probably not relevant as in your previous post the driver configuration does not use dynamical data sets. And the "*Journal" services are not relevant at all (this would be as called 850-Logging).

In Initiate-response, the only really interesting thing, would be - not visible on your screenshot - the number for negociatedMaxServOutstanding. These numbers are limiting the queue size of conformed MMS frames (PDU): a client is allowed to send to server only as many MMS PDUs as stated there. Then client must wait until the server responds at least one PDU.
The screenshot where you show those 6, one-by-one, confirmed-PDUs - is exactly this absolutely allowed scenario; where the negotiated max number was >= 6. So client has sent 6 PDUs and then was waiting until the server responds at least one. Then client may send the next PDU.

I'm proposing you to send sniffs (pcap files, not screenshots) to your COPA-DATA Support.




 

[andrea.ornago]

okkk... problem found ... thanks a lot for your help.

Andrea